Data Security & PDPA

หลายองค์กรทำ PDPA ในรูปแบบ compliance checklist โดยไม่เชื่อมกับ security control ทำให้เมื่อเกิดเหตุ data breach ไม่มีใครตอบได้ว่าข้อมูลใดรั่วและกระทบกับใคร บทนำนี้อธิบายว่าเหตุใด data security จึงต้องเริ่มจาก data discovery และ classification มากกว่าการประกาศนโยบายอย่างเดียว พร้อมสรุปกรอบกฎหมายของไทย (PDPA) และประกาศของ ธปท. ที่องค์กรต้องนำมาประกอบกัน

 

องค์กรจำนวนหนึ่งมองว่าการปฏิบัติตาม PDPA เป็นเรื่องเอกสาร อาทิ การจัดทำ privacy notice และการแต่งตั้ง DPO เพียงอย่างเดียว ขณะที่ข้อกำหนดในประกาศของ PDPC ด้านมาตรการรักษาความมั่นคงปลอดภัยของข้อมูลส่วนบุคคล ระบุถึงการควบคุมเชิงเทคนิคอย่างชัดเจน อาทิ การเข้ารหัส การควบคุมการเข้าถึง การบันทึกการเข้าถึง และการตรวจจับเหตุการณ์ละเมิด การขาดการควบคุมเหล่านี้ทำให้องค์กรตกอยู่ในความเสี่ยงทั้งด้านกฎหมายและด้านปฏิบัติการพร้อมกัน

 

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

 

3.23 M USD

ค่าเฉลี่ยความเสียหายจากเหตุการณ์ข้อมูลรั่วในภูมิภาคอาเซียนต่อเหตุการณ์ (IBM 2024)

 

72 ชั่วโมง

ระยะเวลาที่ผู้ควบคุมข้อมูลส่วนบุคคลต้องแจ้งเหตุการณ์ต่อ PDPC ตาม พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล

 

7 มาตรการ

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

 

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

 

 

CHAPTER ONE · THE FOUNDATION

 

 

เมื่อเกิด data breach คณะกรรมการและหน่วยกำกับมักถามคำถามเดียวกัน — ข้อมูลอะไรรั่ว, จำนวนเท่าไหร่, กระทบกับใคร, เก็บที่ใด, ใครมีสิทธิ์เข้าถึง, เก็บมานานแล้ว, มี legal basis อะไร, มี control อะไรอยู่, และทำไมถึงหลุด การที่ DPO และ CISO ต้องตอบได้ภายใน 2 ชั่วโมง หมายความว่าต้องมี data inventory, access log, retention policy และ control mapping ที่พร้อมใช้ ไม่ใช่ต้องไปตามเอกสารในวันที่เกิดเหตุ

 

“PDPA ที่ดีคือการวาง control ก่อน ไม่ใช่การเขียนเอกสารเพื่อตอบผู้ตรวจสอบเมื่อถูกถาม”

 

 

CHAPTER TWO · THE DISCOVERY

 

 

Data Discovery คือการค้นหาว่าองค์กรเก็บข้อมูลส่วนบุคคล (PII) และข้อมูลอ่อนไหว (sensitive) ไว้ที่ใดบ้าง ในระบบใด และในรูปแบบใด เครื่องมือ native เช่น Microsoft Purview, AWS Macie, Google DLP API ช่วย scan ระบบหลัก ขณะที่ third-party เช่น Varonis, BigID, Dataguise เหมาะสำหรับองค์กรที่มี data source หลากหลาย

 

“ข้อมูลที่คุณไม่รู้ว่ามี = ข้อมูลที่คุณปกป้องไม่ได้”

 

 

CHAPTER THREE · THE PREVENTION

 

 

Data Loss Prevention (DLP) มี 3 รูปแบบการ deploy — Network DLP ที่ scan traffic ที่ gateway, Endpoint DLP ที่ทำงานบน workstation, และ Cloud DLP ที่ integrate กับ SaaS และ cloud storage การเลือก pattern ขึ้นกับ architecture ขององค์กร — องค์กรที่ cloud-first ควรเริ่มจาก Cloud DLP + Endpoint DLP, ขณะที่องค์กรที่ยังมี on-premise เยอะต้องมี Network DLP ด้วย

 

“DLP ที่ไม่เข้าใจ business workflow = เครื่องมือขัดขวางงาน ไม่ใช่ปกป้องข้อมูล”

 

 

CHAPTER FOUR · THE ENCRYPTION

 

 

Encryption at rest ปกป้องข้อมูลเมื่อเก็บใน storage (disk, database, backup) โดยใช้ AES-256 เป็นมาตรฐาน — ประเด็นสำคัญคือ key management ว่า key เก็บที่ไหน (local เครื่องเดียวกัน = ไม่ปลอดภัย, KMS/HSM = ปลอดภัยกว่า) Encryption in transit ปกป้องข้อมูลเมื่อส่งผ่าน network ด้วย TLS 1.2+ และ certificate ที่ถูก manage อย่างเป็นระบบ

 

“Encryption at rest ไม่มีความหมาย ถ้า key อยู่ในเครื่องเดียวกับข้อมูล”

 

 

CHAPTER FIVE · THE RETENTION

 

 

PDPA มาตรา 37(3) กำหนดให้ลบหรือทำให้ข้อมูลไม่ระบุตัวตนเมื่อหมดความจำเป็น — แต่ 'ความจำเป็น' ขึ้นกับ legal basis และ business requirement การออกแบบ retention schedule ที่ใช้งานได้ต้อง map ข้อมูลแต่ละประเภทกับระยะเวลาเก็บ (เช่น เอกสารและ transaction record เก็บตามกฎหมายบัญชีและภาษีที่โดยปกติ 5 ปี แต่บางประเภทอาจยาวกว่าตามข้อกำหนดของหน่วยกำกับเฉพาะภาคธุรกิจ, marketing data เก็บตาม consent, PII พนักงาน เก็บตาม labor law + 2 ปี)

 

“ข้อมูลที่เก็บนานเกินไปคือความเสี่ยงที่สะสมดอกเบี้ย”

 

 

CHAPTER SIX · THE RESPONSE

 

 

PDPA มาตรา 37(4) กำหนดให้แจ้ง PDPC ภายใน 72 ชั่วโมงนับจากที่รู้เหตุ เว้นแต่จะพิสูจน์ได้ว่าไม่มีความเสี่ยงต่อสิทธิและเสรีภาพของเจ้าของข้อมูล และแจ้งเจ้าของข้อมูลโดยไม่ชักช้าหากมีความเสี่ยงสูง การเตรียมพร้อมที่ดีต้องมี — breach assessment template ที่ประเมิน severity ได้ใน 1 ชั่วโมง, notification template สำหรับ PDPC และ data subject, และ escalation path ที่ชัดเจนว่า DPO, CISO, CEO ต้องรับทราบในลำดับใด

 

“72 ชั่วโมงของ PDPA เริ่มนับเมื่อคุณรู้ — ไม่ใช่เมื่อสะดวก”

 

 

PDPA ที่ประสบความสำเร็จไม่ได้เกิดจากการเขียนเอกสารที่ legal approve แต่เกิดจาก security control ที่บังคับ privacy principle ในทุกขั้นตอนของ data lifecycle การออกแบบ data protection architecture ที่ผสาน PDPA compliance กับ technical security จึงเป็นเรื่องของทั้งสายงาน security, legal และ data ไม่ใช่ฝ่ายใดฝ่ายหนึ่ง

 

หากท่านต้องการเนื้อหาฉบับเต็มที่ครอบคลุมทุกบท พร้อมแนวปฏิบัติเชิงเทคนิค ตัวอย่าง workflow และคำศัพท์เฉพาะทาง กดตาม URL นี้เพื่อดาวน์โหลด: