เวลาตี 2 คุณได้รับโทรศัพท์จากฝ่าย IT ว่าพบว่ามีคนเข้าถึงฐานข้อมูลลูกค้าโดยไม่ได้รับอนุญาต นาฬิกาเริ่มนับถอยหลัง 72 ชั่วโมง คุณมีเวลาจำกัดในการประเมินสถานการณ์ ควบคุมความเสียหาย แจ้ง สคส. และแจ้งเจ้าของข้อมูลที่ได้รับผลกระทบ ทุกนาทีมีค่า
บทความนี้จะพาคุณเดินผ่าน Timeline 72 ชั่วโมงอย่างละเอียด พร้อมสิ่งที่ต้องทำในแต่ละช่วงเวลา
กฎหมายกำหนดอะไรบ้าง
PDPA มาตรา 37(4) กำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลต้องแจ้งเหตุการละเมิดข้อมูลส่วนบุคคลแก่ สคส. โดยไม่ชักช้า ภายใน 72 ชั่วโมงนับแต่ทราบเหตุ เว้นแต่การละเมิดนั้นไม่มีความเสี่ยงที่จะมีผลกระทบต่อสิทธิและเสรีภาพของบุคคล
หากเหตุละเมิดมีความเสี่ยงสูงต่อสิทธิและเสรีภาพ ต้องแจ้งเจ้าของข้อมูลที่ได้รับผลกระทบด้วยโดยไม่ชักช้า
Timeline 72 ชั่วโมง: ทีละขั้นตอน
ชั่วโมงที่ 0-4: ตรวจจับและยืนยัน (Detection & Confirmation)
เป้าหมาย: ยืนยันว่าเกิดเหตุ Data Breach จริงหรือไม่
- ตรวจสอบสัญญาณเบื้องต้น — เหตุการณ์ที่ตรวจพบเป็น Data Breach จริงหรือเป็นเพียง security incident ทั่วไป? Data Breach ตาม PDPA หมายถึงเหตุที่ทำให้ข้อมูลส่วนบุคคลรั่วไหล สูญหาย ถูกเข้าถึง ใช้ เปิดเผย แก้ไข หรือทำลายโดยไม่ได้รับอนุญาต
- จัดตั้งทีมตอบสนอง (Incident Response Team) — DPO, ฝ่าย IT Security, ฝ่ายกฎหมาย, ฝ่ายสื่อสาร และผู้บริหารที่เกี่ยวข้อง
- บันทึกทุกอย่าง — เวลาที่ตรวจพบ ใครตรวจพบ สิ่งที่พบ ขั้นตอนที่ดำเนินการ ทุกการตัดสินใจต้องมีบันทึก
จุดสำคัญ: เวลา 72 ชั่วโมงเริ่มนับตั้งแต่ "ทราบเหตุ" ไม่ใช่ตั้งแต่ยืนยันได้ ดังนั้นหากมีเหตุผลอันควรเชื่อว่าเกิด breach แล้ว นาฬิกาเริ่มนับทันที
ชั่วโมงที่ 4-12: ควบคุมและประเมิน (Containment & Assessment)
เป้าหมาย: หยุดความเสียหายไม่ให้ขยายตัว และประเมินขอบเขต
- ควบคุมเหตุ (Containment) — ตัดการเข้าถึงที่ไม่ได้รับอนุญาต ปิดช่องโหว่ที่ถูกใช้โจมตี แยกระบบที่ได้รับผลกระทบ แต่อย่าลบหลักฐาน
- ประเมินขอบเขต — ข้อมูลอะไรถูกเข้าถึง ปริมาณเท่าไร มีข้อมูลอ่อนไหว (sensitive data) หรือไม่ กี่คนได้รับผลกระทบ
- ประเมินความเสี่ยง — ความเสี่ยงต่อสิทธิและเสรีภาพของเจ้าของข้อมูลอยู่ในระดับใด พิจารณาจากประเภทข้อมูล ปริมาณ ลักษณะการรั่วไหล และความเป็นไปได้ที่จะถูกนำไปใช้ในทางที่ผิด
ชั่วโมงที่ 12-24: เตรียมการแจ้งเตือน (Notification Preparation)
เป้าหมาย: เตรียมเอกสารแจ้งเตือนที่ครบถ้วน
- ตัดสินใจว่าต้องแจ้งหรือไม่ — หากเหตุละเมิดมีความเสี่ยงต่อสิทธิและเสรีภาพ (ซึ่งในกรณีส่วนใหญ่ถือว่ามี) ต้องแจ้ง สคส.
- เตรียมรายงานแจ้ง สคส. — ร่างรายงานที่ครอบคลุมทุกประเด็นที่ต้องรายงาน (ดูรายละเอียดด้านล่าง)
- เตรียมการแจ้งเจ้าของข้อมูล — หากมีความเสี่ยงสูง ต้องเตรียมข้อความแจ้งเจ้าของข้อมูลด้วย
ชั่วโมงที่ 24-48: แจ้งเตือน (Notification)
เป้าหมาย: แจ้ง สคส. และเจ้าของข้อมูล (ถ้าจำเป็น)
- แจ้ง สคส. — ส่งรายงานการละเมิดข้อมูลผ่านช่องทางที่ สคส. กำหนด
- แจ้งเจ้าของข้อมูล — ส่งการแจ้งเตือนผ่านช่องทางที่เข้าถึงได้โดยตรง เช่น อีเมล SMS หรือจดหมาย
- เตรียมรับมือคำถามและข้อร้องเรียน — จัดทีมรับสายและตอบอีเมลจากเจ้าของข้อมูลที่ได้รับการแจ้งเตือน
ชั่วโมงที่ 48-72: แก้ไขและติดตาม (Remediation & Follow-up)
เป้าหมาย: แก้ไขสาเหตุรากเหง้าและป้องกันไม่ให้เกิดซ้ำ
- แก้ไขช่องโหว่ — ดำเนินการแก้ไขช่องโหว่ที่เป็นสาเหตุอย่างถาวร
- เก็บหลักฐาน — เก็บรักษา log files, forensic images และหลักฐานทั้งหมด
- ส่งรายงานเพิ่มเติม — หากมีข้อมูลใหม่ที่ยังไม่ได้รายงานในรอบแรก ต้องส่งรายงานเพิ่มเติมให้ สคส.
- เริ่มกระบวนการ Post-Incident Review — วิเคราะห์สาเหตุ จุดอ่อน และแผนป้องกัน
สิ่งที่ต้องรายงานต่อ สคส.
รายงานการแจ้งเตือนเหตุละเมิดต้องครอบคลุมอย่างน้อย 7 ประเด็นหลัก
- ลักษณะของเหตุละเมิด — เกิดอะไรขึ้น ด้วยวิธีการใด
- ข้อมูลที่ได้รับผลกระทบ — ประเภทข้อมูลส่วนบุคคลที่รั่วไหล มีข้อมูลอ่อนไหวหรือไม่
- จำนวนเจ้าของข้อมูลที่ได้รับผลกระทบ — หรือประมาณการเบื้องต้นหากยังไม่ทราบจำนวนที่แน่นอน
- ผลกระทบที่อาจเกิดขึ้น — ความเสี่ยงต่อเจ้าของข้อมูลมีอะไรบ้าง
- มาตรการที่ได้ดำเนินการ — ทำอะไรไปแล้วเพื่อควบคุมเหตุและลดผลกระทบ
- มาตรการป้องกันในอนาคต — แผนการแก้ไขเพื่อไม่ให้เกิดซ้ำ
- ข้อมูลติดต่อ DPO — ชื่อ ช่องทางติดต่อของ DPO หรือผู้ประสานงาน
สิ่งสำคัญ: หากยังประเมินขอบเขตไม่เสร็จภายใน 72 ชั่วโมง ให้แจ้งเท่าที่ทราบก่อน แล้วส่งรายงานเพิ่มเติมภายหลัง อย่ารอจนทราบทุกอย่างแล้วค่อยแจ้ง เพราะจะเกินกำหนดเวลา
โครงร่างเทมเพลตการแจ้งเตือนเจ้าของข้อมูล
การแจ้งเตือนเจ้าของข้อมูลควรมีเนื้อหาดังนี้
- หัวเรื่องที่ชัดเจน: แจ้งว่าเป็นการแจ้งเตือนเหตุละเมิดข้อมูลส่วนบุคคล
- สิ่งที่เกิดขึ้น: อธิบายเหตุการณ์โดยสังเขปในภาษาที่เข้าใจง่าย
- ข้อมูลที่ได้รับผลกระทบ: ระบุประเภทข้อมูลของเจ้าของข้อมูลที่รั่วไหล
- สิ่งที่องค์กรดำเนินการแล้ว: มาตรการที่ใช้ควบคุมเหตุและลดผลกระทบ
- สิ่งที่เจ้าของข้อมูลควรทำ: คำแนะนำในการป้องกันตนเอง เช่น เปลี่ยนรหัสผ่าน ระวังอีเมลหลอกลวง ตรวจสอบธุรกรรม
- ช่องทางติดต่อ: หมายเลขโทรศัพท์และอีเมลสำหรับสอบถามเพิ่มเติม
- สิทธิของเจ้าของข้อมูล: แจ้งสิทธิในการร้องเรียนต่อ สคส.
8 ข้อผิดพลาดที่พบบ่อยในการรับมือ Data Breach
ไม่รู้ว่าเกิด Breach
หลายองค์กรไม่มีระบบตรวจจับ (monitoring) ที่มีประสิทธิภาพ ทำให้ทราบว่าเกิด breach ช้ามาก บางครั้งหลายเดือนหลังจากเกิดเหตุ ยิ่งรู้ช้า ยิ่งเสียหายมาก นี่คือข้อผิดพลาดที่พบบ่อยที่สุดและส่งผลกระทบรุนแรงที่สุด
ลบหลักฐานระหว่างควบคุมเหตุ
ในความตื่นตระหนก ทีม IT อาจ format เครื่อง หรือลบ log files เพื่อ "ทำความสะอาด" ซึ่งทำลายหลักฐานที่จำเป็นสำหรับการสืบสวนและรายงาน กฎง่าย ๆ คือ: ควบคุมเหตุได้ แต่ห้ามลบร่องรอย
รอข้อมูลครบถ้วนก่อนค่อยแจ้ง
ข้อนี้เป็นกับดักที่องค์กรตั้งใจดีก็ยังพลาด 72 ชั่วโมงไม่รอใคร หากรอจนประเมินเสร็จสมบูรณ์ มักจะเกินกำหนดเวลา แนวปฏิบัติที่ถูกต้องคือแจ้งเท่าที่ทราบก่อน แล้วส่งข้อมูลเพิ่มเติมภายหลัง
แผน Incident Response ที่ไม่เคยซ้อม
มีแผนบนกระดาษแต่ไม่เคยซ้อม เมื่อเกิดเหตุจริงจึงสับสน ไม่รู้ว่าใครต้องทำอะไร ช่องทางสื่อสารไม่พร้อม แผนที่ไม่เคย test ก็แทบไม่ต่างจากไม่มีแผน
การสื่อสารภายในที่ขาดเอกภาพ
ข้อมูลกระจัดกระจาย ผู้บริหารได้รับข้อมูลคนละเวอร์ชัน ทีมงานไม่รู้สถานะปัจจุบัน ปัญหานี้รุนแรงขึ้นเป็นทวีคูณในองค์กรที่มีหลายสาขาหรือหลายแผนก
ภาษาที่เข้าใจยากในการแจ้งเจ้าของข้อมูล
ใช้ศัพท์เทคนิคที่เจ้าของข้อมูลทั่วไปไม่เข้าใจ หรือแจ้งอย่างคลุมเครือจนไม่รู้ว่าต้องทำอะไร การแจ้งเตือนที่ดีต้องตอบคำถาม 3 ข้อให้ชัด: เกิดอะไรขึ้น ส่งผลกระทบอะไรกับคุณ แล้วต้องทำอะไรบ้าง
ลืมแจ้ง Data Processor ที่เกี่ยวข้อง
Vendor ที่ประมวลผลข้อมูลแทนอาจมีข้อมูลที่เกี่ยวข้องกับเหตุ breach ด้วย การไม่แจ้ง processor ทำให้ขอบเขตของเหตุการณ์ไม่ชัด และอาจมีข้อมูลรั่วไหลที่ยังไม่ถูกตรวจพบ
ไม่ทำ Post-Incident Review
หลังจบเหตุแล้วก็เดินหน้าต่อ ไม่วิเคราะห์สาเหตุรากเหง้า ไม่ปรับปรุงกระบวนการ ปัญหาเดิมจึงมีโอกาสเกิดซ้ำ องค์กรที่จัดการ breach ได้ดีมักเป็นองค์กรที่เคยเรียนรู้จากเหตุก่อนหน้าอย่างจริงจัง
เตรียมพร้อมก่อนเกิดเหตุ ดีกว่าวิ่งตามหลัง
Data Breach เป็นเรื่องของ "เมื่อไหร่" ไม่ใช่ "ถ้า" ทุกองค์กรมีโอกาสเผชิญเหตุ สิ่งที่แตกต่างคือระดับความพร้อมในการรับมือ
การเตรียมพร้อมที่ดีต้องมี 3 องค์ประกอบ ได้แก่ แผนที่ชัดเจน (Plan) ทีมที่ฝึกมาแล้ว (People) และเครื่องมือที่พร้อมใช้ (Platform)
PrivacyHub มีโมดูล Breach Management ที่ออกแบบมาเพื่อรองรับ Timeline 72 ชั่วโมงนี้โดยเฉพาะ ตั้งแต่การบันทึกเหตุ การประเมินความเสี่ยงด้วย Genesis AI การสร้างรายงานแจ้ง สคส. อัตโนมัติ การแจ้งเตือนเจ้าของข้อมูล ไปจนถึง Post-Incident Review ทุกขั้นตอนถูกบันทึกเป็น Immutable Audit Trail ที่พิสูจน์ได้ว่าองค์กรดำเนินการอย่างถูกต้องตามกฎหมาย
Genesis AI ช่วยวิเคราะห์ความเสี่ยงของเหตุ breach โดยอัตโนมัติ แนะนำขั้นตอนที่ต้องดำเนินการ และช่วยร่างรายงานแจ้งเตือน เพื่อให้ทีมของคุณทำงานได้อย่างรวดเร็วและถูกต้องภายในเวลาที่จำกัด
เตรียมพร้อมวันนี้ที่ enersys.co.th/th/products/privacyhub
