pakkapol.ke

[post-views]

pakkapol.ke
pakkapol.ke

คำชี้แจง

กรณีศึกษานี้เขียนสำหรับเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) และผู้ปฏิบัติงานด้าน PDPA

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

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

กรณีศึกษาจำลองเพื่อการศึกษา ชื่อองค์กร บุคคล และเหตุการณ์ทั้งหมดเป็นเรื่องสมมติ

ขอเลื่อนไปไตรมาสหน้า

บ่ายวันพฤหัสบดี

โทรศัพท์บนโต๊ะของ วรรณา ดังขึ้นเป็นครั้งที่สามภายในสิบนาที

“พี่วรรณารู้เรื่องนี้หรือยังคะ” น้องฝ่ายประชาสัมพันธ์ถาม “มีนักข่าวโทรมาถามว่าข้อมูลลูกค้าเราหลุดจริงไหม โพสต์ในเฟซบุ๊กตอนนี้แชร์กันไปเกินหมื่นแล้ว”

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

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

แต่จนถึงนาทีนั้น เธอก็ยังไม่รู้ว่าเกิดอะไรขึ้น…

ย้อนกลับไปเมื่อ 6 วันก่อน

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

เขาพบว่า ข้อมูลสมาชิกราว 380,000 รายการ ถูกดึงออกไปผ่าน API Key ของบริษัทรับจ้างพัฒนาระบบที่หมดสัญญาไปตั้งแต่ปีที่แล้ว แต่ Key นั้นยังใช้งานได้อยู่

เช้าวันเสาร์ ทีมไอทีทั้งสี่คน นั่งอัดกันอยู่ในห้องประชุมเล็ก พร้อมกับกาแฟในแก้วที่เย็นชืด

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

น้องในทีมจึงเอ่ยถามเบา ๆ ว่า “ทำไม Key เก่าถึงยังไม่ถูกยกเลิก”

ธนากรได้แต่หัวเราะแห้ง ๆ “งบทำระบบจัดการสิทธิ พี่ขอไปตั้งแต่ปีที่แล้ว ได้คำตอบว่าขอเลื่อนไปไตรมาสหน้า”

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

ตลอดวันจันทร์จนถึงวันพุธ

ฝ่ายคอลเซ็นเตอร์รับสายร้องเรียนเพิ่มขึ้นทุกวัน ลูกค้าบอกว่ามีคนโทรมาอ้างเป็นพนักงานของบริษัท และขอให้
“ยืนยันตัวตนเพื่อรับเงินคืน” พนักงานบันทึกไว้ว่าเป็นแก๊งคอลเซ็นเตอร์ทั่วไป ไม่มีใครเชื่อมโยงเรื่องนี้กับการแจ้งเตือนเมื่อคืนวันศุกร์เลย

บ่ายวันพุธ

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

“คุณป้าได้รับเงินคืนส่วนต่างครับ แต่ระบบต้องยืนยันบัญชีก่อน”

ยี่สิบนาทีต่อมา เงิน 460,000 บาทถูกโอนออกจากบัญชีของเธอ

วันพฤหัสบดี โพสต์ของลูกค้าอีกคนกลายเป็นไวรัล และโทรศัพท์บนโต๊ะของวรรณาก็เริ่มดังขึ้น

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

ลำดับเหตุการณ์

วัน

เหตุการณ์

ผู้รับทราบเหตุการณ์

DPO รับทราบหรือไม่

วันที่ 1
(ศุกร์ 19.40 น.)

แจ้งเตือน API ผิดปกติ ข้อมูล 380,000 รายการถูกดึงผ่าน Key ของผู้รับจ้างที่หมดสัญญา

ฝ่ายไอที

ไม่ทราบ

วันที่ 2 (เสาร์)

ทีมไอทีปิด Key และตั้งสถานะ “ยังไม่ยืนยันการรั่วไหล”

ฝ่ายไอที

ไม่ทราบ

วันที่ 4–6
(จันทร์–พุธ)

ลูกค้าร้องเรียนเรื่องมิจฉาชีพ ลูกค้ารายหนึ่งเสียเงิน 460,000 บาท

คอลเซ็นเตอร์

ไม่ทราบ

วันที่ 7 (พฤหัสบดี)

ผู้เสียหายโพสต์ในโซเชียลมีเดีย นักข่าวติดต่อบริษัท

สาธารณะ ฝ่ายประชาสัมพันธ์

ทราบจากฝ่ายประชาสัมพันธ์

วันที่ 8
(ศุกร์ 16.40 น.)

บริษัทแจ้งเหตุต่อ สคส.

ทั้งองค์กร

ทราบ

ผลที่ตามมา

คณะกรรมการผู้เชี่ยวชาญมีคำสั่งลงโทษปรับทางปกครอง ฐานแจ้งเหตุล่าช้าและไม่มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม พร้อมสั่งให้แก้ไขระบบภายใน 90 วัน

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

สมาชิกยกเลิกบัญชีจำนวนมาก ธนาคารพันธมิตรระงับโครงการบัตรเครดิตร่วมชั่วคราว คณะกรรมการบริษัทตั้งทีมสอบสวนภายใน

เอกสารสองฉบับ

สัปดาห์ที่สองของการสอบสวน ทีมพบบันทึกสองฉบับในแฟ้มฝ่ายกฎหมาย ซึ่งเปลี่ยนคำถามของคดีจาก “ใครทำพลาด” เป็น “บริษัทรู้มาตั้งแต่เมื่อไร”

วันที่

  ผู้เสนอ         

สาระของข้อเสนอ

คำตอบท้ายบันทึก

14 มีนาคม ปีที่แล้ว             

 วรรณา

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

“ขอเลื่อนไปไตรมาสหน้า งบไอทียังไม่ลง”

2 กันยายน ปีที่แล้ว

 วรรณา

ข้อเสนอเดิม และเพิ่มการตรวจสอบและยกเลิกสิทธิของผู้รับจ้างที่หมดสัญญาทั้งหมด

“ขอเลื่อนไปไตรมาสหน้า”

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

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

ประเด็นทางกฏหมาย

คำถาม

หน้าที่ตามกฎหมาย

ข้อเท็จจริงในกรณีนี้

บทที่เกี่ยวข้อง

มีมาตรการความมั่นคงปลอดภัยที่เหมาะสมหรือไม่

มาตรา 37(1) ต้องจัดให้มีมาตรการที่เหมาะสม ทบทวนเมื่อจำเป็น และเป็นไปตามมาตรฐานขั้นต่ำที่คณะกรรมการประกาศกำหนด

API key ของผู้รับจ้างที่หมดสัญญายังใช้งานได้ ทั้งที่ DPO เสนอให้ยกเลิกเป็นลายลักษณ์อักษร

ปรับทางปกครองไม่เกิน 3 ล้านบาท (มาตรา 83)

แจ้งเหตุทันเวลาหรือไม่

มาตรา 37(4) แจ้ง สคส. โดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ทราบเหตุเท่าที่จะสามารถกระทำได้ เว้นแต่ไม่มีความเสี่ยงต่อสิทธิและเสรีภาพ ถ้ามีความเสี่ยงสูงต้องแจ้งเจ้าของข้อมูลพร้อมแนวทางเยียวยาโดยไม่ชักช้า

แจ้ง สคส. ที่ 165 ชั่วโมง ลูกค้ารู้จากโซเชียลมีเดียก่อนได้รับแจ้งจากบริษัท

ปรับทางปกครองไม่เกิน 3 ล้านบาท (มาตรา 83)

สนับสนุนให้ DPO ทำงานได้จริงหรือไม่

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

มาตรา 42 วรรคสาม เมื่อมีปัญหาในการปฏิบัติหน้าที่ DPO ต้องสามารถรายงานต่อผู้บริหารสูงสุดโดยตรงได้

DPO ไม่มีสิทธิเข้าถึงระบบแจ้งเตือน ไม่อยู่ในสายแจ้งเหตุฉุกเฉิน ข้อเสนอขอเครื่องมือถูกเลื่อนสองครั้ง

ปรับทางปกครองไม่เกิน 1 ล้านบาท (มาตรา 82)

ผู้ใดต้องชดใช้ และต้องชดใช้เท่าไร

มาตรา 77 ผู้ควบคุมข้อมูลต้องชดใช้ความเสียหายจากการฝ่าฝืน ไม่ว่าจงใจหรือประมาทเลินเล่อหรือไม่ เว้นแต่พิสูจน์ข้อยกเว้นได้

มาตรา 78 ศาลสั่งค่าสินไหมเพื่อการลงโทษเพิ่มได้ไม่เกินสองเท่าของค่าสินไหมที่แท้จริง

ผู้เสียหายรายหนึ่งถูกหลอกโอนเงิน 460,000 บาท คดียังอยู่ระหว่างพิจารณา

ความรับผิดทางแพ่ง

จุดที่ DPO ต้องอ่านให้ละเอียด

“ทราบเหตุ” ไม่ใช่ “ยืนยันได้” มาตรา 37(4) นับจากทราบเหตุ ข้ออ้างว่ารอตรวจสอบให้ชัดก่อน แต่ถ้อยคำ “เท่าที่จะสามารถกระทำได้” เปิดช่องให้โต้แย้งเรื่องจังหวะเวลาได้บ้าง ในกรณีนี้ช่องนั้นแคบมาก เพราะฝ่ายไอทีเห็นการดึงข้อมูล 380,000 รายการตั้งแต่คืนแรก

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

มาตรา 42 วรรคสาม กรณีที่มีปัญหาในการปฎิบัติหน้าที่ เจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลต้องสามารถรายงานไปยังผู้บริหารสูงสุดของผู้ควบคุมข้อมูลส่วนบุคคลหรือผู้ประมวลผลข้อมูลส่วนบุคคลโดยตรงได้

ค่าเสียหาย 460,000 บาทยังเป็นข้อโต้แย้งได้ มาตรา 77(1) ยกเว้นกรณีความเสียหายเกิดจากการกระทำของเจ้าของข้อมูลเอง บริษัทอาจยกว่าผู้เสียหายเป็นผู้โอนเงินเอง ขณะที่ฝ่ายโจทก์จะชี้ว่ามิจฉาชีพหลอกได้เพราะข้อมูลที่รั่วจากบริษัท และบริษัทไม่เตือนลูกค้าทั้งที่รู้เรื่องตั้งแต่วันเสาร์

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

บทเรียนสำหรับ DPO

การมี DPO ไม่ได้ช่วยให้องค์กรพ้นความรับผิดชอบตามกฎหมาย ถ้า DPO ไม่อยู่ในเส้นทางที่ข้อมูลเหตุการณ์ไหลผ่าน

สิ่งที่อยู่นอกเหนืออำนาจของ DPO

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

สิ่งที่ DPO ทำได้มากกว่านี้

  • ใช้สิทธิรายงานตรง เมื่อข้อเสนอถูกเลื่อนเป็นครั้งที่สอง วรรณามีช่องทางตามมาตรา 42 วรรคสาม แต่ไม่ได้ใช้
  • คุยกับฝ่ายไอทีโดยตรง เธอส่งบันทึกไปตามสายบังคับบัญชา แต่ไม่เคยตกลงกับฝ่ายไอทีว่ากรอบ 72 ชั่วโมงเริ่มนับเมื่อไร
  • ใช้อำนาจตรวจสอบของตน มาตรา 42(2) ให้ DPO ตรวจสอบการดำเนินงานรวมถึงผู้รับจ้าง เธอขอให้คนอื่นตรวจ แต่ไม่ได้ตรวจเอง
  • เปลี่ยนบันทึกให้เป็นการตัดสินใจที่มีเจ้าของ บันทึกที่ได้คำตอบว่า “ขอเลื่อน” ควรตามด้วยคำขอให้ผู้บริหารลงนามรับความเสี่ยงพร้อมวันทบทวน
  • ในฐานะ DPO ควรมีการอบรมเรื่อง PDPA ในองค์กร เมื่อเกิดเหตุ Data Breach จะได้มีการรับมืออย่างถูกต้อง

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

ข้อเสนอแนะเชิงระบบ

ด้าน

การดำเนินการ

ฝ่ายที่ DPO ร่วมทำงาน

แผนรับมือเหตุละเมิด

ระบุ DPO เป็นผู้รับแจ้งลำดับแรกเมื่อ “สงสัย” ว่ามีเหตุ

ฝ่ายไอที ผู้บริหารสูงสุด

เกณฑ์ยกระดับเหตุ

กำหนดระดับเหตุพร้อมตัวอย่าง เช่น การดึงข้อมูลจำนวนมากผิดปกติ = แจ้ง DPO ทันที

ฝ่ายไอที ฝ่ายความมั่นคงปลอดภัย

บุคคลภายนอก

เพิกถอนสิทธิทันทีเมื่อสิ้นสุดสัญญา และตรวจทานเป็นรอบ

ฝ่ายไอที ฝ่ายจัดซื้อ

การยอมรับความเสี่ยง

บันทึกเหตุผล ชื่อผู้ยอมรับความเสี่ยง และวันทบทวน

ผู้บริหารระดับสูง

ช่องทางรายงานตรง

ทำให้ช่องทางตามมาตรา 42 วรรคสามเป็นขั้นตอนที่เขียนไว้

ผู้บริหารสูงสุด คณะกรรมการบริษัท

สัญญาณจากลูกค้า

ฝึกคอลเซ็นเตอร์ให้ทราบรูปแบบเรื่องร้องเรียนที่บ่งชี้ว่าข้อมูลรั่ว

ฝ่ายบริการลูกค้า

เช็กลิสต์สำหรับองค์กร

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

คำถามอภิปราย

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

หมายเหตุการอ้างอิงและแหล่งที่มา

dpo in action อบรม pdpa dpo
DPOinActionรุ่น19 1200x300

coloktoto

toto

coloktoto