สรุปเนื้อหาการสัมมนา: PDPA Guru - ถอดบทเรียน การประเมินความเสี่ยง หลังเกิด Data Breach องค์กรต้องเตรียมตัวอย่างไร?

ข้อมูลทั่วไป

• วันที่และเวลา: วันเสาร์ที่ 1 สิงหาคม 2568 เวลา 15.00 น.

• วิทยากร:

  • ดร. อุดมธิปก ไพรเกษตร

  • อาจารย์สุกฤษ โกยอัครเดช

  • อาจารย์ไผท โฆษจันทร

  • อาจารย์วิวัฒน์ กอสัมพันธ์

• รูปแบบ: (Webinar) การถอดบทเรียนและให้ความรู้เกี่ยวกับการประเมินความเสี่ยง

บทนำ

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

วัตถุประสงค์ของการประเมินความเสี่ยงและความเชื่อมโยงกับ PDPA

อาจารย์วิวัฒน์ อธิบายว่า ตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล (PDPA) เหตุการณ์ละเมิดข้อมูลส่วนบุคคล (Data Breach) ไม่ได้หมายถึงเพียงแค่ข้อมูลรั่วไหลออกนอกองค์กรเท่านั้น แต่กฎหมายยังนิยามถึงการละเมิดข้อมูลส่วนบุคคลใน 3 รูปแบบหลัก ได้แก่ การละเมิดความลับ (Confidentiality Breach), การละเมิดความถูกต้องสมบูรณ์ (Integrity Breach), และการละเมิดความพร้อมใช้งาน (Availability Breach) โดยไม่จำเป็นต้องครบทั้งสามด้าน หากเกิดการละเมิดเพียงด้านใดด้านหนึ่งก็ถือเป็นเหตุละเมิดข้อมูลส่วนบุคคลแล้ว ไม่ว่าจะเกิดจากการจงใจหรือไม่จงใจก็ตาม

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

• ไม่มีความเสี่ยงต่อสิทธิเสรีภาพของบุคคล: ไม่จำเป็นต้องแจ้งสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC หรือ สคส.)

• มีความเสี่ยงที่จะมีผลกระทบต่อสิทธิเสรีภาพของบุคคล: ต้องแจ้ง สคส. ภายใน 72 ชั่วโมงนับแต่ทราบเหตุ

• มีความเสี่ยงสูงที่จะมีผลกระทบต่อสิทธิเสรีภาพของบุคคล: ต้องแจ้งทั้ง สคส. และแจ้งเจ้าของข้อมูลส่วนบุคคลให้ทราบด้วย

บทบาทของผู้ควบคุมข้อมูลส่วนบุคคลและเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO)

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

ขั้นตอนการประเมินความเสี่ยงและการรับมือเหตุละเมิดข้อมูลส่วนบุคคล (Step-by-Step)

อาจารย์ไผท ได้เน้นย้ำถึงในมุมมองของ Cybersecurity จะต้องเตรียมความพร้อม (Preparation) ก่อนเกิดเหตุการณ์ โดยมีขั้นตอนทางเทคนิคที่สำคัญดังนี้

1. การตรวจจับ (Detection) และการวิเคราะห์ (Analysis): เมื่อได้รับแจ้งเหตุข้อมูลรั่วไหล องค์กรต้องมีกระบวนการตรวจสอบว่าข้อมูลรั่วไหลจริงหรือไม่ เพื่อหลีกเลี่ยง False Positive (แจ้งเตือนผิดพลาด) และ False Negative (ข้อมูลรั่วไหลแต่ไม่รู้ตัว) ต้องยืนยันว่าข้อมูลที่เกี่ยวข้องเป็นข้อมูลส่วนบุคคลหรือไม่ และมีการเข้าถึง แก้ไข หรือสูญหายจริงหรือไม่ เครื่องมือ เช่น SIEM (Security Information and Event Management) หรือ DLP (Data Loss Prevention) สามารถช่วยในการตรวจจับได้

2. การจำกัดความเสียหาย (Containment): เมื่อยืนยันว่าเกิดเหตุการณ์จริง ต้องดำเนินการจำกัดขอบเขตความเสียหายทันที เช่น การบล็อก IP, การระงับการใช้งานเครื่องที่ถูกโจมตี เพื่อป้องกันไม่ให้ความเสียหายขยายวงกว้างออกไป

3. การเก็บหลักฐาน (Preservation Evidence): เป็นขั้นตอนที่สำคัญอย่างยิ่ง ห้ามรีบปิดเครื่องหรือรีสตาร์ทระบบทันทีที่เกิดเหตุ เพราะอาจทำให้หลักฐานที่ใช้ในการสืบสวนหาต้นตอของการโจมตีสูญหายไปได้ การเก็บหลักฐานเป็นสิ่งจำเป็นสำหรับการต่อสู้คดีในอนาคตและเพื่อพิสูจน์ว่าองค์กรได้ดำเนินการอย่างเหมาะสม

4. การกำจัด (Eradication) และการกู้คืน (Recovery): หลังจากจำกัดความเสียหายและเก็บหลักฐานแล้ว จึงจะดำเนินการกำจัดสาเหตุของการละเมิด (เช่น มัลแวร์) และกู้คืนระบบหรือข้อมูลให้กลับมาใช้งานได้ตามปกติ

สรุปขั้นตอนการรับมือเหตุละเมิดข้อมูลส่วนบุคคล

กรณีศึกษา: โรงพยาบาลกับการทำลายข้อมูลเวชระเบียน

ดร. อุดมธิปก ยกกรณีศึกษาของโรงพยาบาลขนาดใหญ่ที่ถูกลงโทษจากการจ้างธุรกิจ SME ขนาดเล็กให้ทำลายข้อมูลเวชระเบียน (ล้มแฟ้ม) ซึ่งเป็นข้อมูลกระดาษ [1], [2] โดยไม่ได้มีการกำกับดูแลหรือตรวจสอบวิธีการทำลายข้อมูลอย่างเพียงพอ กรณีนี้ชี้ให้เห็นประเด็นสำคัญหลายประการ:

• การละเมิดข้อมูลไม่ได้เกิดจากการแฮกเสมอไป: ในกรณีนี้ การละเมิดเกิดจากการที่ข้อมูลถูกส่งมอบให้บุคคลภายนอก (SME) โดยไม่มีมาตรการรักษาความปลอดภัยที่เพียงพอ และ SME เองก็ไม่มีความรู้ความเข้าใจใน PDPA

• ความรับผิดชอบของผู้ควบคุมข้อมูลส่วนบุคคล: โรงพยาบาลในฐานะผู้ควบคุมข้อมูลส่วนบุคคลยังคงต้องรับผิดชอบ แม้จะจ้างผู้ประมวลผลข้อมูลส่วนบุคคล (SME) มาดำเนินการก็ตาม หากผู้ประมวลผลไม่มีมาตรการรักษาความปลอดภัยที่เหมาะสม ผู้ควบคุมข้อมูลส่วนบุคคลก็อาจถูกปรับด้วยเช่นกัน

• ความเข้าใจผิดของ SME: ธุรกิจ SME หลายรายอาจเข้าใจผิดว่าตนเองไม่ต้องปฏิบัติตาม PDPA หรือไม่เข้าใจว่าการรับจ้างทำลายข้อมูลก็ถือเป็นการประมวลผลข้อมูลส่วนบุคคลที่ต้องมีมาตรการรักษาความปลอดภัยและข้อตกลงการประมวลผลข้อมูลส่วนบุคคล (Data Processing Agreement - DPA) ที่ชัดเจน

• การทำลายข้อมูลต้องเป็นไปตามหลักการ PDPA: การทำลายข้อมูลต้องมั่นใจว่าข้อมูลถูกลบอย่างถาวรและไม่สามารถเข้าถึงได้อีก แม้จะเป็นข้อมูลกระดาษก็ตาม การวางทิ้งไว้หรือการทำลายที่ไม่เหมาะสมก็ถือเป็นการละเมิดได้

ข้อมูลเพิ่มเติมที่น่าสนใจ ความคิดเห็นทางวิชาการส่วนตัวของนพ.นวนรรน ธีระอัมพรพันธุ์ [3] ต่อกรณีของ "โรงพยาบาลเอกชนขนาดใหญ่รายหนึ่ง ซึ่งปรากฏภาพถุงขนมโตเกียวที่ทำจากเอกสารเวชระเบียนของผู้ป่วย ถูกเผยแพร่ผ่านโซเชียลมีเดีย”

การประเมินความเสี่ยง

อาจารย์วิวัฒน์ อธิบายว่า ในทางกฎหมาย การประเมินความเสี่ยงจะไม่ได้มีการระบุขั้นตอนอย่างชัดเจน แต่บอกเกณฑ์การประเมินความเสี่ยงว่าประเมินมาจากหลายปัจจัย (ห้ามใช้ปัจจัยเดียว) เช่น ปัจจัยประเภทของการละเมิด เช่น การละเมิดความลับ และประเภทของข้อมูลส่วนบุคคล เช่น ข้อมูลสุขภาพผู้ป่วย ที่เป็นข้อมูลพิเศษ และปริมาณข้อมูลที่เกิดการละเมิด เช่น 1 หรือ 1,000 คน ซึ่งในองค์กรขนาดใหญ่มักจะใช้การประเมินโอกาศ (Likelihood) และความรุนแรง (Impact) มาใช้ในการทำ Risk Assessment Matrix

การประเมินโอกาส (Likelihood) และความรุนแรง (Impact)

• การประเมินโอกาส (Likelihood) เรามักจะสร้าง Risk Scenario เพื่อมาพิจารณาว่า จะมีโอกาสเกิดกรณีตาม Risk Scenario มากน้อยแค่ไหน

• การประเมินความรุนแรง (Impact) กรณีที่เกิดขึ้นส่งผลอย่างไร เช่น ข้อมูลที่หลุดสามารถระบุตัวตนได้เข้าใกล้กับ data subject มากขนาดไหน หรือ ข้อมูลหลุด 1%, 5% ก็วิกฤต เพราะด้าน compliance ถ้าข้อมูลหลุดจะโดนปรับเงิน ไปจนถึงการส่งผลกระทบทางด้านภาพลักษณ์แหละทางธุรกิจ

ในทางธุรกิจจะมองว่าข้อมูลส่วนบุคคลวไม่ได้เป็นความลับทางธุรกิจ ทำให้มุมมองของ DPO, Data Governance แตกต่างกัน

• DPO จะมองในมุมมองของ Data Subject ไม่ใช่มุมมองขององค์กร ซึ่งจะประเมินความรุนแรงในมุม Data Subject ว่าส่งผลกับเขาอย่างไร

• Data Governance จะมองในมุมมองขององค์กร ทำให้ประเมินความรุนแรงว่าส่งผลต่อองค์กรและธุรกิจอย่างไร เช่น ข้อมูลหลุดแล้วโดนปรับโดนฟ้อง หรือผิด Compliance

บทบาทและความสำคัญของเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO)

บทบาทของ DPO อาจแตกต่างกันไปตามขนาดและโครงสร้างขององค์กร แต่มีหน้าที่หลักที่สำคัญร่วมกัน ดังนี้

บทบาทตามขนาดขององค์กร

• องค์กรขนาดเล็กถึงขนาดกลาง: DPO มักจะทำหน้าที่ทั้งในฐานะ ที่ปรึกษา (Advisor) และ ผู้ปฏิบัติงาน (Doer) คือเป็นทั้งผู้วางแผน ให้คำแนะนำ และลงมือปฏิบัติงานเอง

• องค์กรขนาดใหญ่: DPO อาจทำหน้าที่เป็น ที่ปรึกษา (Advisor) เป็นหลัก โดยมีคณะทำงานหรือบอร์ดเข้ามาช่วยในการตัดสินใจและปฏิบัติงาน

หน้าที่ความรับผิดชอบหลักของ DPO

ไม่ว่าองค์กรจะมีขนาดใด DPO จะมีบทบาทสำคัญที่เหมือนกัน โดยเฉพาะเมื่อเกิดเหตุข้อมูลรั่วไหล ดังนี้

1. เป็นศูนย์กลาง (Center):

   • DPO ต้องเป็นจุดศูนย์กลางที่รับรู้ข้อมูลเกี่ยวกับเหตุการณ์ด้านข้อมูลส่วนบุคคลทั้งหมดในองค์กร

   • แม้ว่าเหตุการณ์จะเกิดในฝ่ายไอที แต่ DPO ต้องรับทราบเรื่องราวทั้งหมด เพื่อให้สามารถประเมินสถานการณ์และบริหารจัดการได้อย่างถูกต้องและทันท่วงที

2. บริหารจัดการเหตุการณ์ (Incident Management):

   • รวบรวมข้อเท็จจริง: DPO มีหน้าที่สั่งการให้ฝ่ายต่างๆ ที่เกี่ยวข้องรวบรวมข้อเท็จจริงทั้งหมดที่เกิดขึ้น

   • ประเมินสถานการณ์: นำข้อเท็จจริงมาประเมินว่าเหตุการณ์ดังกล่าวเข้าเกณฑ์ที่ต้องแจ้งต่อ สคส. และ/หรือเจ้าของข้อมูลส่วนบุคคลหรือไม่

   • ควบคุมกรอบเวลา 72 ชั่วโมง: บริหารจัดการกระบวนการต่างๆ เพื่อให้สามารถแจ้งเหตุต่อ สคส. ได้ทันภายใน 72 ชั่วโมงตามที่กฎหมายกำหนด

3. ประสานงานกับฝ่ายต่างๆ (Coordination):

   • DPO ทำหน้าที่เป็น จุดประสานงานกลาง (Contact Point) เพื่อให้การจัดการเหตุการณ์เป็นไปอย่างราบรื่นและสอดคล้องกับกฎหมาย

   • การรายงานต่อ สคส.: จัดเตรียมรายงานข้อเท็จจริงเพื่อยื่นต่อ สคส.

   • การสื่อสารกับเจ้าของข้อมูล: ทำงานร่วมกับฝ่ายสื่อสารองค์กรหรือฝ่ายประชาสัมพันธ์ เพื่อกำหนดเนื้อหา ช่องทาง และรูปแบบการแจ้งเตือนเจ้าของข้อมูลส่วนบุคคล (Data Subject) ให้เหมาะสมและครบถ้วนตามกฎหมาย ป้องกันกรณีที่เนื้อหาการสื่อสารไม่สอดคล้องกับข้อกฎหมาย

เครื่องมือที่ช่วยในการวิเคราะห์และประเมินหลังจากข้อมูลรั่วไหล

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

1. การเตรียมรับมือ (Workflow)

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

ในโลกของ IT ก็เช่นกัน เมื่อเกิดเหตุข้อมูลรั่วไหล เราต้องมี Workflow (เวิร์คโฟลว์) หรือ ขั้นตอนการปฏิบัติงาน ที่ชัดเจนว่าใครควรแจ้งใคร ใครเป็นผู้รับผิดชอบ และต้องดำเนินการอย่างไร โดยปกติแล้วเราสามารถใช้ระบบต่างๆ เข้ามาช่วยได้:

• ระบบอีเมล (Email System): ใช้สำหรับการแจ้งเตือนเหตุการณ์และสื่อสารกันภายในองค์กร

• ระบบโทรศัพท์ (Phone System): สำหรับการสื่อสารเร่งด่วนเมื่อเกิดเหตุการณ์ฉุกเฉิน

• ระบบ IT Service Management (ITSM): เป็นระบบที่ช่วยในการจัดการเหตุการณ์ต่างๆ ในองค์กร เช่น เมื่อพนักงานพบเห็นข้อมูลรั่วไหล สามารถเปิด "Ticket" เพื่อแจ้งเหตุการณ์ได้ ซึ่งระบบจะส่งเรื่องต่อไปยังผู้รับผิดชอบที่เกี่ยวข้อง เพื่อให้ดำเนินการตรวจสอบและแก้ไขได้อย่างรวดเร็ว

2. การระบุและยืนยันตัวตน (Identify)

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

ในด้านเทคโนโลยี เครื่องมือที่ช่วยในการระบุตัวตน ได้แก่:

• ไฟล์บันทึกกิจกรรม (Log Files): เปรียบเสมือนสมุดบันทึกเหตุการณ์ทั้งหมดที่เกิดขึ้นในระบบ เราสามารถตรวจสอบ Log Files เพื่อดูว่ามีใครเข้าถึงข้อมูลอะไรบ้าง เข้าถึงเมื่อไหร่ และมีการกระทำที่น่าสงสัยหรือไม่

• ระบบยืนยันตัวตน (Authentication System): ระบบนี้ใช้ในการตรวจสอบว่าผู้ที่พยายามเข้าถึงระบบเป็นบุคคลที่ได้รับอนุญาตจริงหรือไม่ เช่น การเข้าสู่ระบบด้วยชื่อผู้ใช้งานและรหัสผ่าน หากมีผู้พยายาม "แฮก" หรือพยายามสวมรอยเป็นผู้อื่น ระบบยืนยันตัวตนจะสามารถบันทึกข้อมูลและแจ้งเตือนได้

3. การตรวจจับและควบคุมการแพร่กระจาย (Detect & Contain)

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

ในด้านเทคโนโลยี เครื่องมือที่ช่วยในการตรวจจับและควบคุมการแพร่กระจายของข้อมูลรั่วไหล ได้แก่:

• ระบบตรวจจับการบุกรุก (Intrusion Detection System - IDS) และระบบป้องกันการบุกรุก (Intrusion Prevention System - IPS): เปรียบเสมือนกล้องวงจรปิดที่คอยเฝ้าระวังความผิดปกติในบ้าน หากตรวจพบการเคลื่อนไหวที่น่าสงสัย (เช่น มีข้อมูลรั่วไหลออกไปอย่างรวดเร็ว) ระบบจะแจ้งเตือนหรือบล็อกการกระทำนั้นทันที

• ระบบ Circuit Breaker (เซอร์กิตเบรกเกอร์): ในทางไฟฟ้า เซอร์กิตเบรกเกอร์จะตัดวงจรเมื่อเกิดกระแสไฟเกิน เพื่อป้องกันความเสียหาย ในระบบ IT ก็มีหลักการคล้ายกัน คือการมีกลไกที่สามารถ "ตัด" การเชื่อมต่อ หรือ "หยุด" การทำงานของระบบบางส่วน เพื่อป้องกันไม่ให้ข้อมูลรั่วไหลไปมากกว่านี้

4. การกู้คืนข้อมูล (Recovery)

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

ในด้านเทคโนโลยี เราต้องมี แผนการกู้คืนจากภัยพิบัติ (Disaster Recovery Plan - DRP) ซึ่งเปรียบเสมือนแผนสำรองว่าหากบ้านไฟไหม้ เราจะขนย้ายของสำคัญไปที่ไหน และจะกลับมาดำเนินชีวิตปกติได้อย่างไร DRP จะช่วยให้องค์กรสามารถ:

• กู้คืนข้อมูลสำรอง (Backup Data): การสำรองข้อมูลเป็นสิ่งสำคัญอย่างยิ่ง หากข้อมูลเสียหายหรือถูกทำลาย เราสามารถนำข้อมูลที่สำรองไว้กลับมาใช้งานได้

• กู้คืนระบบ (System Restoration): การทำให้ระบบที่ได้รับผลกระทบกลับมาทำงานได้ตามปกติ

5. การบริหารจัดการวิกฤต (Crisis Management)

บางครั้ง แม้จะทำทุกอย่างดีที่สุดแล้ว แต่สถานการณ์ก็อาจรุนแรงจนไม่สามารถกู้คืนได้ทันที หรือเกิดเหตุการณ์ที่เกินความคาดหมาย สิ่งนี้คือ ภาวะวิกฤต เหมือนกับการที่ไฟไหม้บ้านจนไม่สามารถซ่อมแซมได้ทันที

ในสถานการณ์เช่นนี้ องค์กรต้องมี แผนการบริหารจัดการวิกฤต (Crisis Management Plan) ซึ่งรวมถึง:

• งบประมาณสำรอง: การมีงบประมาณที่เพียงพอสำหรับจ้างผู้เชี่ยวชาญภายนอกมาช่วยกู้คืนระบบและข้อมูล

• การสื่อสารกับผู้มีส่วนได้ส่วนเสีย: การแจ้งให้ผู้ที่ได้รับผลกระทบทราบถึงสถานการณ์และการดำเนินการต่างๆ อย่างโปร่งใส

6. การฝึกซ้อมและเตรียมพร้อม (Preparation)

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

การลงทุนในการรักษาความปลอดภัยของข้อมูล

ประเมินการลงทุนเปรียบเทียบกับค่าปรับเป็นหลัก เช่น การลงทุนในมาตรการรักษาความปลอดภัยของสารสนเทศ เปรียบเทียบกับรายได้ เปรียบเทียบกับเงินค่าปรับ

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

การแจ้งเหตุละเมิดข้อมูลส่วนบุคคล (Data Breach) ต่อเจ้าของข้อมูล (Data Subject)

ในการแจ้งเหตุละเมิดข้อมูลส่วนบุคคล (Data Breach) ต่อเจ้าของข้อมูล (Data Subject) กฎหมายอาจไม่ได้ระบุรูปแบบหรือวิธีการที่ตายตัว แต่มีหลักการสำคัญที่ควรยึดถือเพื่อให้การสื่อสารมีประสิทธิภาพ สะท้อนความรับผิดชอบ และสร้างความน่าเชื่อถือให้กับองค์กร

ข้อความที่ "ควร" ใส่ในการแจ้งเตือน

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

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

• ช่องทางการติดต่อ: ระบุช่องทางที่เจ้าของข้อมูลสามารถติดต่อสอบถาม หรือขอข้อมูลเพิ่มเติมได้ เช่น เบอร์โทรศัพท์ อีเมล หรือเว็บไซต์ ควรระบุชื่อผู้ประสานงานหลัก หรือ เจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) หรือตัวแทนที่รับผิดชอบ

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

• แนวทางการเยียวยา/มาตรการป้องกันตนเอง: แนะนำสิ่งที่เจ้าของข้อมูลควรทำเพื่อลดความเสี่ยงหรือป้องกันตนเอง เช่น การเปลี่ยนรหัสผ่าน การตรวจสอบบัญชีธนาคาร หรือการระมัดระวังอีเมลและข้อความที่น่าสงสัย

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

ข้อความที่ "ไม่ควร" ใส่ในการแจ้งเตือน

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

• การใช้ภาษาทางเทคนิคที่ซับซ้อน: ควรใช้ภาษาที่เข้าใจง่าย ไม่ควรใช้ศัพท์เฉพาะทางเทคนิคที่เจ้าของข้อมูลทั่วไปอาจไม่เข้าใจ

• การกล่าวโทษผู้อื่น หรือปัดความรับผิดชอบ: ไม่ควรกล่าวโทษบุคคลอื่น ฝ่ายอื่น หรือผู้ให้บริการภายนอกว่าเป็นต้นเหตุของเหตุการณ์ เพราะในมุมมองของกฎหมายและเจ้าของข้อมูล องค์กรในฐานะ "ผู้ควบคุมข้อมูล" (Data Controller) มีหน้าที่รับผิดชอบหลักในการคุ้มครองข้อมูล

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

3 C ขั้นตอนสำคัญสำหรับการจัดการข้อมูลรั่วไหล

1. Contract (สัญญา)

ก่อนที่จะให้บริการแก่ลูกค้ารายใดควรตรวจสอบและทำความเข้าใจเรื่องสัญญาอย่างละเอียด สิ่งสำคัญคือ:

• Service Level Agreement (SLA): ทำความเข้าใจว่าลูกค้าคาดหวังอะไรจาก SLA โดยเฉพาะอย่างยิ่งในเรื่องของความพร้อมใช้งานของระบบและความปลอดภัยของข้อมูล

• Data Processing Agreement (DPA): ตรวจสอบให้แน่ใจว่าได้มีการจัดทำ DPA กับลูกค้าหรือไม่ DPA เป็นข้อตกลงที่ระบุรายละเอียดความรับผิดชอบของผู้ให้บริการ ในฐานะผู้ประมวลผลข้อมูล ซึ่งจะช่วยให้เกิดความโปร่งใส (Transparency) และกำหนดขอบเขตความรับผิดชอบเมื่อเกิดเหตุละเมิดข้อมูล

• การจ้างช่วง (Sub-processors): ผู้ให้บริการ มักมีการจ้างช่วงผู้ให้บริการรายอื่น (Sub-processors) เพื่อดำเนินงาน เช่น ผู้ให้บริการ Server, Network, หรือ Hardware สิ่งสำคัญคือต้องตรวจสอบสัญญาเหล่านั้นว่ามีมาตรการความปลอดภัยที่เพียงพอหรือไม่ และมีการกำหนดความรับผิดชอบในการตอบสนองต่อเหตุการณ์ความปลอดภัยทางไซเบอร์ (Cyber Security Incident Response) ภายในกรอบระยะเวลาที่ชัดเจนหรือไม่

2. Contact (การติดต่อสื่อสาร)

เมื่อเกิดเหตุการณ์ขึ้น ผู้ให้บริการ ไม่ควรนิ่งเฉยหรือรอให้ลูกค้าติดต่อมา แต่ควรรีบดำเนินการดังนี้:

• แจ้งเตือนลูกค้าทันที: เมื่อรับทราบหรือสงสัยว่าเกิดเหตุการณ์ Data Breach ควรรีบแจ้งลูกค้า (Data Controller/Cloud Customer) โดยเร็วที่สุด เพื่อให้พวกเขาทราบถึงสถานการณ์และสามารถดำเนินการตามแผนของตนเองได้

• การอัปเดตสถานะอย่างต่อเนื่อง: ในสถานการณ์ฉุกเฉิน การสื่อสารที่ต่อเนื่องเป็นสิ่งสำคัญมาก ควรมีการกำหนด Service Level Agreement (SLA) สำหรับการอัปเดตสถานะความคืบหน้าของการแก้ไขปัญหา เช่น ทุก 30 นาที หรือทุก 1 ชั่วโมง เพื่อให้ลูกค้าสบายใจและรับทราบถึงสิ่งที่กำลังดำเนินการอยู่ แม้ในขณะนั้นจะยังไม่สามารถแก้ไขปัญหาได้เสร็จสิ้น

3. Content & Compliance (เนื้อหาและการปฏิบัติตามกฎหมาย)

สุดท้าย ผู้ให้บริการ ต้องมั่นใจว่าตนเองมีมาตรการและกระบวนการที่ชัดเจนในการจัดการกับ Data Breach และปฏิบัติตามข้อกำหนดทางกฎหมาย:

• กระบวนการจัดการเหตุการณ์ (Incident Response Workflow): ควรมี Workflow ที่ชัดเจนสำหรับเหตุการณ์ Data Breach ตั้งแต่การตรวจจับ (Detect) การตอบสนอง (Respond) ไปจนถึงการกู้คืน (Recovery) โดยครอบคลุมทั้งด้าน People (บุคลากร), Process (กระบวนการ), และ Technology (เทคโนโลยี)

• มาตรการป้องกันข้อมูล: มีมาตรการปกป้องข้อมูลที่รับผิดชอบจากลูกค้าอย่างเพียงพอและสอดคล้องกับมาตรฐานความปลอดภัย

• การปฏิบัติตามกฎหมาย: ผู้ให้บริการ Cloud มีหน้าที่ต้องแจ้งเหตุ Data Breach ให้กับหน่วยงานกำกับดูแลที่เกี่ยวข้อง หากกฎหมายกำหนดให้ต้องดำเนินการนั้น และต้องเข้าใจถึงข้อกำหนดในการแจ้งเตือนแก่เจ้าของข้อมูลตามกฎหมายที่เกี่ยวข้อง

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

ความรับผิดชอบของผู้ประมวลผลข้อมูล (Processor) และประเด็นสำคัญในกรณีข้อมูลรั่วไหล

แม้ว่าผู้ควบคุมข้อมูล (Controller) จะเป็นผู้รับผิดชอบหลักในการคุ้มครองข้อมูลส่วนบุคคล แต่ผู้ประมวลผลข้อมูล (Processor) ก็มีบทบาทสำคัญและไม่สามารถละเลยความรับผิดชอบได้เลย โดยเฉพาะเมื่อเกิดเหตุการณ์ข้อมูลรั่วไหล (Data Breach) จากกรณีศึกษาที่ สคส. (สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล) ได้ประกาศออกมา พบว่ามีผู้ประมวลผลข้อมูลถูกปรับไปแล้วหลายราย ซึ่งยืนยันว่า แม้ไม่มี Data Processing Agreement (DPA) ผู้ประมวลผลก็ยังคงมีหน้าที่ต้องป้องกันความเสี่ยงจากการรั่วไหลของข้อมูลส่วนบุคคล

กรณีศึกษาที่น่าสนใจ: การปรับผู้ประมวลผลข้อมูลที่ไม่มี DPA

สคส. ได้ชี้แจงชัดเจนในกรณีแรกที่หน่วยงานรัฐแห่งหนึ่งมีข้อมูลรั่วไหลกว่า 200,000 รายชื่อไปปรากฏบน Dark Web ว่า หนึ่งในสาเหตุสำคัญคือไม่มีการทำ DPA อย่างไรก็ตาม สคส. ได้เน้นย้ำว่า การไม่มี DPA ไม่ได้เป็นข้ออ้างให้ผู้ประมวลผลละเลยการดำเนินการใดๆ เพื่อป้องกันความเสี่ยงของข้อมูล ซึ่งหมายความว่าไม่ว่าจะมี DPA หรือไม่ ผู้ประมวลผลก็ยังมีหน้าที่ตามกฎหมายที่จะต้องมีมาตรการรักษาความปลอดภัยที่เพียงพอและเหมาะสมเพื่อคุ้มครองข้อมูลที่ตนเองประมวลผลอยู่

ความซับซ้อนของการจัดการข้อมูลรั่วไหล สำหรับผู้ให้บริการ SaaS

สำหรับผู้ให้บริการซอฟต์แวร์แบบบริการ (SaaS) ซึ่งเป็นผู้ประมวลผลข้อมูลรายใหญ่ ความท้าทายจะยิ่งซับซ้อนขึ้นเมื่อเกิดข้อมูลรั่วไหล เนื่องจาก:

• ผลกระทบต่อลูกค้าหลายรายพร้อมกัน: หากข้อมูลรั่วไหลจากระบบของผู้ให้บริการ SaaS จะไม่กระทบเพียงแค่ผู้ควบคุมข้อมูลรายเดียว แต่มีโอกาสที่จะกระทบลูกค้า (ผู้ควบคุมข้อมูล) หลายรายพร้อมกัน

• การแจ้งเตือนหลายฝ่าย: ในกรณีนี้ ผู้ให้บริการ SaaS จะต้อง:

  • แจ้งผู้ควบคุมข้อมูลที่เป็นลูกค้าทุกราย ที่ได้รับผลกระทบ เพื่อให้แต่ละรายไปประเมินผลกระทบต่อลูกค้าของตนเอง (Data Subjects) และดำเนินการแจ้ง สคส. ต่อไป

  • แจ้ง สคส. ด้วยตนเอง หากมีความจำเป็นตามข้อกำหนดของกฎหมาย

• ความแตกต่างของผลกระทบ: แม้ข้อมูลจะรั่วไหลจากระบบเดียวกัน แต่ผลกระทบต่อผู้ควบคุมข้อมูลแต่ละรายอาจไม่เท่ากัน ขึ้นอยู่กับประเภทและปริมาณข้อมูลที่แต่ละรายฝากไว้ในระบบของผู้ให้บริการ SaaS ดังนั้น ผู้ประมวลผลข้อมูลอาจต้องช่วยผู้ควบคุมข้อมูลในการประเมินผลกระทบที่แตกต่างกันไปในแต่ละราย

ประเด็นเรื่อง Data Protection Impact Assessment (DPIA)

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

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

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

• สถานะปัจจุบันของการตัดสิน: คำสั่งทางปกครองจากคณะกรรมการผู้เชี่ยวชาญของ สคส. ถือเป็นที่สุด แต่ผู้ร้อง (Data Subject) และผู้ถูกร้อง (Controller/Processor) ยังมีสิทธิ์อุทธรณ์คำสั่งต่อ ศาลปกครอง ภายใน 90 วันนับจากวันที่ได้รับคำสั่ง ดังนั้น บรรทัดฐานที่แท้จริงจะปรากฏชัดเจนเมื่อมีคำพิพากษาจากศาลปกครองออกมา

บรรทัดฐานใหม่: สคส. เป็นผู้ร้องเองได้ ไม่ต้องรอเจ้าทุกข์

ประเด็นที่น่าสนใจอย่างยิ่งและเป็นบรรทัดฐานใหม่ในการบังคับใช้กฎหมาย PDPA คือ กรณีที่เกิดขึ้นกับโรงพยาบาลเอกชน ซึ่ง ผู้ร้องไม่ใช่เจ้าของข้อมูล (Data Subject) แต่เป็น สคส. เอง

• การดำเนินการของ สคส.: เจ้าหน้าที่ สคส. ตรวจพบการละเมิดข้อมูลส่วนบุคคลบนสื่อออนไลน์ (เช่น รูปภาพข้อมูลผู้ป่วยถูกโพสต์บนโซเชียลมีเดีย) จึงได้ตั้งเรื่องสืบสวนสอบสวนและนำเข้าคณะกรรมการผู้เชี่ยวชาญเพื่อพิจารณาลงโทษ

• ความหมายต่อองค์กร: กรณีนี้เปลี่ยนแนวคิดเดิมที่ว่าต้องมีเจ้าของข้อมูลเป็นเจ้าทุกข์มาร้องเรียนก่อน สคส. ถึงจะดำเนินการได้ ในปัจจุบัน สคส. สามารถตรวจพบปัญหาและดำเนินการเองได้ทันที

• ความเสี่ยงใหม่สำหรับองค์กร: องค์กรจำเป็นต้องเปลี่ยนการประเมินความเสี่ยงใหม่ จากเดิมที่อาจมองแค่ว่า "จะมีคนร้อง สคส. หรือไม่" มาเป็น "หากข้อมูลรั่วไหลหรือมีการละเมิดสิทธิของเจ้าของข้อมูล และปรากฏต่อสาธารณะ ไม่ว่าจะเป็นบน Dark Web หรือ Social Media ก็ตาม สคส. อาจเข้ามาดำเนินการได้ทันที แม้ไม่มีผู้ร้องเรียนโดยตรง"

• การเฝ้าระวัง: องค์กรจึงไม่ควรจำกัดการเฝ้าระวังแค่ Dark Web เท่านั้น แต่ควรมีทีมหรือมาตรการในการติดตาม Social Media อย่างใกล้ชิด เพื่อตรวจจับการละเมิดข้อมูลที่อาจเกิดขึ้นและเผยแพร่อยู่บนแพลตฟอร์มสาธารณะ ก่อนที่ สคส. จะตรวจพบและดำเนินการ

การประเมินความเสี่ยงด้านข้อมูลส่วนบุคคล: เมื่อเกณฑ์ขององค์กรไม่ตรงกับ PDPC

หากกฎหมายไม่ได้ระบุเกณฑ์ความเสี่ยงที่ชัดเจน การประเมินความเสี่ยงขององค์กรอาจไม่ตรงกับวิธีการหรือเกณฑ์ของคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC หรือ สคส.) ซึ่งอาจก่อให้เกิดปัญหาได้ แล้วองค์กรควรทำอย่างไร?

หลักการพื้นฐาน: ความเสี่ยงแต่ละองค์กรไม่เท่ากัน

ประเด็นนี้ต้องทำความเข้าใจก่อนว่า "ความเสี่ยงของแต่ละองค์กรไม่เท่ากัน" เช่นเดียวกับฐานะทางการเงินของแต่ละบุคคล องค์กรแต่ละประเภทมีความแตกต่างกันในด้าน:

• ประเภทธุรกิจ: ธุรกิจการเงินย่อมมีความเสี่ยงสูงกว่าธุรกิจโรงแรม เนื่องจากจัดการข้อมูลที่มีความละเอียดอ่อนและมูลค่าสูงกว่า

• ประเภทข้อมูลส่วนบุคคลที่จัดเก็บ: องค์กรที่จัดเก็บข้อมูลส่วนบุคคลที่มีความละเอียดอ่อนสูง (Sensitive Personal Data) เช่น ข้อมูลสุขภาพ ย่อมมีความเสี่ยงมากกว่า

• ปริมาณข้อมูล: องค์กรที่จัดเก็บข้อมูลจำนวนมากย่อมมีความเสี่ยงสูงกว่าองค์กรที่จัดเก็บข้อมูลจำนวนน้อย

ดังนั้น การที่กฎหมายไม่ได้ฟันธงเกณฑ์ความเสี่ยงที่ตายตัว จึงเป็นเรื่องที่สมเหตุสมผล เพราะไม่มี "One Size Fits All" หรือเกณฑ์เดียวที่ใช้ได้กับทุกองค์กร

แนวทางปฏิบัติเพื่อประเมินความเสี่ยงให้สอดคล้องกับ PDPC

ในเมื่อไม่มีเกณฑ์ที่ชัดเจน องค์กรควรเริ่มต้นจาก:

• เปรียบเทียบกับธุรกิจในอุตสาหกรรมเดียวกัน (Compare Apple to Apple):

  • พิจารณาจากแนวปฏิบัติในอุตสาหกรรม: องค์กรควรศึกษาว่าธุรกิจที่ใกล้เคียงกันในอุตสาหกรรมเดียวกันมีการประเมินความเสี่ยงอย่างไร มีการให้ความสำคัญกับมาตรการป้องกันแบบใดบ้าง

  • พิจารณากลุ่มลูกค้า (Data Subject) และ Supply Chain ที่คล้ายกัน: ธุรกิจที่คล้ายกันมักจะมีกลุ่มลูกค้าและ Supply Chain ที่ใกล้เคียงกัน ซึ่งจะสะท้อนถึงประเภทและความละเอียดอ่อนของข้อมูลที่ต้องประมวลผล ทำให้การประเมินความเสี่ยงมีความเหมาะสมยิ่งขึ้น

• เริ่มต้นจากการพยายามและปรับปรุงอย่างต่อเนื่อง (Continual Improvement):

  • อย่ารอช้าที่จะเริ่มต้น: แม้จะไม่รู้เกณฑ์ที่ชัดเจน องค์กรก็ควรเริ่มต้นประเมินความเสี่ยงและกำหนดมาตรการป้องกันในระดับหนึ่งก่อน

  • ปรับปรุงตามผลการประเมิน: เมื่อเริ่มต้นแล้ว ให้ประเมินและปรับปรุงอย่างต่อเนื่อง หากพบว่าเกณฑ์ที่ตั้งไว้บางเกินไป หนาเกินไป หรือสร้างภาระให้องค์กรมากเกินไป ก็สามารถปรับแต่ง (Customize) ได้เรื่อยๆ

หลักการลงทุนในความปลอดภัย: ลงทุนเพื่อ "กำไร" ทางความเสี่ยง

สิ่งที่สำคัญคือ องค์กรควรลงทุนในมาตรการรักษาความปลอดภัยข้อมูลให้ "ได้กำไรทางความเสี่ยง"

• ประเมินต้นทุนการถูกปรับหรือเสียหาย: หากองค์กรประเมินแล้วว่ามีโอกาสถูกปรับ 10 ล้านบาท หากเกิด Data Breach การลงทุนในมาตรการรักษาความปลอดภัยเกิน 10 ล้านบาทก็อาจจะไม่คุ้มค่า

• ลงทุนอย่างชาญฉลาด: หากความเสี่ยงสูงสุดคือถูกปรับ 10 ล้านบาท การลงทุนในระบบรักษาความปลอดภัย 5 ล้านบาท (น้อยกว่า 50% ของความเสี่ยง) หากสามารถลดความเสี่ยงลงได้อย่างมีนัยสำคัญ ก็ถือเป็นการลงทุนที่ได้ "กำไร" เพราะมีส่วนต่าง 5 ล้านบาทที่สามารถนำไปใช้จ่ายในกรณีที่เกิดเหตุไม่คาดฝันในปีถัดไป และที่สำคัญคือได้กำไรในด้าน ภาพลักษณ์ขององค์กร (Brand Value) ซึ่งประเมินค่าไม่ได้

• ป้องกันดีกว่าแก้ไข: "ต้นทุนในการป้องกันมักจะถูกกว่าต้นทุนในการแก้ไขเสมอ" การลงทุนในมาตรการเชิงป้องกัน (Preventive Measures) เช่น ระบบรักษาความปลอดภัย การฝึกอบรมพนักงาน ย่อมคุ้มค่ากว่าการรอให้เกิดเหตุการณ์แล้วค่อยมาแก้ไข (Corrective Measures) ซึ่งอาจมีค่าใช้จ่ายสูงกว่ามาก ทั้งในด้านตัวเงิน ชื่อเสียง และความน่าเชื่อถือขององค์กร

สิ่งที่องค์กรและ DPO มักมองข้ามเมื่อเกิดข้อมูลรั่วไหล

อ. วิวัฒน์ ชี้ให้เห็นว่าในสถานการณ์ Data Breach ผู้บริหารและ DPO มักประเมินต่ำไปหรือมองข้ามบางประเด็นสำคัญ โดยสิ่งที่มักถูกมองข้ามคือ "การรับมือในสถานการณ์จริง" (Real-life Incident Response) แม้หลายองค์กรจะมีแผนและเคยซ้อมแผนรับมือ Data Breach เพียงปีละครั้ง (เช่นเดียวกับการซ้อมหนีไฟ) แต่เมื่อเหตุการณ์เกิดขึ้นจริงภายใต้กรอบเวลา 72 ชั่วโมงตามที่กฎหมายกำหนด ความท้าทายที่แท้จริงจะอยู่ที่:

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

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

คำแนะนำ: องค์กรควรพิจารณาการซ้อมแผนรับมือ Data Breach ให้บ่อยขึ้นและจริงจังมากขึ้น เพื่อให้บุคลากรเกิดความคุ้นเคยและสามารถรับมือได้อย่างเป็นระบบเมื่อเกิดเหตุการณ์จริง

คำกล่าวปิดท้าย: สิ่งที่ DPO, CTO, CIO ควรกังวล และแนวทางการก้าวไปข้างหน้า

ในฐานะผู้รับผิดชอบหลักในการจัดการข้อมูลในองค์กร ทั้ง DPO, CTO, และ CIO ต่างต้องเผชิญกับความท้าทายเรื่อง Data Breach ซึ่งไม่มีใครอยากให้เกิดขึ้น แต่สิ่งที่สำคัญกว่าคือ "เราจะรับมือกับมันได้อย่างไร"

การวางแผนรับมืออย่างมีประสิทธิภาพ

Data Breach หรือเหตุการณ์ไม่พึงประสงค์ต่างๆ ในองค์กร ไม่มีใครอยากให้เกิดขึ้น เหมือนกับที่เราไม่อยากให้รถชนหรือบ้านไฟไหม้ แต่เมื่อเกิดแล้ว การวางแผนรับมือล่วงหน้าอย่างมีประสิทธิภาพจะช่วยลดผลกระทบและต้นทุนที่ตามมาได้ สิ่งสำคัญคือการพิจารณาสัดส่วนของงบประมาณด้าน Security Budget และ Privacy Budget ขององค์กร

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

• อ้างอิงจากค่าปรับ: หากยังไม่มีงบประมาณที่ชัดเจน ลองพิจารณาจากกรณีศึกษาค่าปรับที่เกิดขึ้นจริง เพื่อใช้เป็นเหตุผลในการตั้งงบประมาณ

• ลงทุนใน 3 ด้านหลัก (People, Process, Technology):

  • People (บุคลากร): พัฒนาความรู้ความสามารถของบุคลากร เพื่อให้สามารถดำเนินการได้อย่างถูกต้องเมื่อเกิดเหตุการณ์

  • Process (กระบวนการ): สร้างกระบวนการที่ถูกต้อง เหมาะสมกับองค์กร และสามารถปฏิบัติได้จริง ไม่ใช่แค่ลอกเลียนแบบมา

  • Technology (เทคโนโลยี): ใช้เทคโนโลยีที่เหมาะสมในการสนับสนุนการทำงาน เช่น Firewall, Data Loss Prevention (DLP) หากยังไม่มีโซลูชันราคาแพง ก็สามารถพิจารณาใช้บริการ Managed Service ซึ่งเป็นการจ้างผู้ให้บริการภายนอกมาดูแล หรือใช้ Freeware ที่ต้องมีผู้เชี่ยวชาญคอยดูแลจัดการ

ในชีวิตจริงควรคิดว่า "การโดน Data Breach เป็นสิ่งที่ต้องโดนแน่ๆ แค่ยังไม่รู้ว่าเมื่อไหร่" ดังนั้น การป้องกันไว้ล่วงหน้าย่อมดีกว่าการตามแก้ไขปัญหาภายหลัง

มุมมองเชิงกฎหมาย: โทษทางแพ่งและ Class Action

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

• คำสั่งทางปกครองเป็นองค์ประกอบในการฟ้องแพ่ง: เมื่อมีคำสั่งทางปกครองว่าองค์กรกระทำผิดจริง จะทำให้การฟ้องร้องทางแพ่งไม่ต้องเสียเวลาสืบพยานมากนัก เหลือเพียงการพิจารณาค่าเสียหายที่จะเรียกร้องเท่านั้น

• การฟ้องร้องแบบกลุ่ม (Class Action): คดี PDPA สามารถฟ้องร้องแบบกลุ่มได้ (เป็นคดีผู้บริโภค) ซึ่งในประเทศไทยยังไม่พบเห็นเคสแบบนี้มากนัก แต่ไม่ได้หมายความว่าจะไม่มีในอนาคต หากมีคดีฟ้องร้องแบบกลุ่มเกิดขึ้น ค่าเสียหายที่องค์กรต้องรับผิดชอบอาจสูงกว่าค่าปรับทางปกครองมาก

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

ข้อมูลเพิ่มเติม

• ตัวอย่างการประเมินความเสี่ยง: สำหรับผู้ที่ต้องการเห็นตัวอย่างการประเมินความเสี่ยงเมื่อเกิดข้อมูลรั่วไหล สคส. เคยเผยแพร่คู่มือ "คู่มือแนวทางการประเมินความเสี่ยงและแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล เวอร์ชั่น ๑.๐" ซึ่งมีตัวอย่างสถานการณ์การประเมินความเสี่ยงประมาณ 10 เคส สามารถดาวน์โหลดได้ที่เว็บไซต์ [4]

• การเก็บข้อมูลนานกว่า 10 ปี: หากกฎหมายกำหนดให้เก็บข้อมูล 10 ปี และหากมีการปกปิดข้อมูลส่วนบุคคล "โดยการลบหรือทำลาย" อย่างสมบูรณ์ ทำให้ไม่สามารถระบุตัวบุคคลได้อีกต่อไป (Anonymization) ก็อาจเก็บข้อมูลนั้นในรูปแบบที่ไม่สามารถระบุตัวตนได้นานกว่า 10 ปี หรือนานกว่าระยะเวลาที่ประเมินความเสี่ยงได้ อย่างไรก็ตาม หากเป็นการปกปิดแต่ยังสามารถย้อนกลับมาเชื่อมโยงกับตัวบุคคลได้ (Pseudonymization) และยังถือว่าเป็นข้อมูลส่วนบุคคล การเก็บข้อมูลยังคงต้องพิจารณาตามความจำเป็นและเหตุผลตามกฎหมาย สำหรับรายละเอียดเพิ่มเติม สามารถศึกษาได้จากกฎหมายลูกที่เกี่ยวข้องกับหลักเกณฑ์การลบ ทำลาย หรือทำให้ข้อมูลเป็นนิรนาม ซึ่ง สคส. ได้อัปเดตออกมาแล้ว [5]

ข้อมูลอ้างอิง

[1] ลงโทษปรับ 1.2 ล้านบาท รพ.เอกชน ปม "ถุงขนมโตเกียว" จาก "เวชระเบียนผู้ป่วย". สืบค้นเมื่อ 2 สิงหาคม 2568, จาก https://www.thaipbs.or.th/news/content/354970

[2] เก็บข้อมูลประชาชนให้ดี หลุดไปเป็นถุงขนมโตเกียว โดนปรับเป็นล้าน. สืบค้นเมื่อ 2 สิงหาคม 2568, จาก https://marketeeronline.co/archives/427678

[3] ความคิดเห็นทางวิชาการส่วนตัวของนพ.นวนรรน ธีระอัมพรพันธุ์ ต่อกรณีของ “โรงพยาบาลเอกชนขนาดใหญ่รายหนึ่ง ซึ่งปรากฏภาพถุงขนมโตเกียวที่ทำจากเอกสารเวชระเบียนของผู้ป่วย ถูกเผยแพร่ผ่านโซเชียลมีเดีย” สืบค้นเมื่อ 2 สิงหาคม 2568, https://www.facebook.com/nawanan/posts/pfbid0269CmX32KRBj2snexjreY4x7tBLEM23ejv3tb1JetXP31AxAoEKhNddqMy4Dsc93sl

[4] คู่มือแนวทางการประเมินความเสี่ยงและแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล เวอร์ชั่น ๑.๐. สืบค้นเมื่อ 2 สิงหาคม 2568, จาก https://www.dga.or.th/document/106114/

[5] ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์ในการลบหรือทำลาย หรือทำให้ข้อมูลส่วนบุคคลเป็นข้อมูลที่ไม่สามารถระบุตัวบุคคลที่เป็นเจ้าของข้อมูลส่วนบุคคลได้ พ.ศ. 2567. สืบค้นเมื่อ 2 สิงหาคม 2568, https://www.pdpc.or.th/7020/