PDPA กับ Cybersecurity — บทบาทและข้อจำกัดของ Pentest

พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (Personal Data Protection Act — PDPA) ไม่ใช่แค่กฎหมายเรื่องความยินยอม (Consent) เท่านั้น แต่ยังกำหนดให้องค์กรต้องมี มาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม ด้วย บทความนี้อธิบายว่าทำไม Penetration Testing (Pentest) ช่วยประเมินมาตรการทางเทคนิคตามขอบเขตได้ แต่ไม่รับรอง compliance ทั้งหมด

มาตรา 37(1) — หัวใจด้าน Security ของ PDPA

มาตรา 37(1) กำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) ต้อง “จัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม เพื่อป้องกันการสูญหาย เข้าถึง ใช้ เปลี่ยนแปลง แก้ไข หรือเปิดเผยข้อมูลส่วนบุคคลโดยปราศจากอำนาจหรือโดยมิชอบ” [1]

คำว่า “เหมาะสม” ไม่ได้กำหนดรายละเอียดเฉพาะเจาะจง แต่หมายความว่าองค์กรต้องพิสูจน์ได้ว่ามีมาตรการที่สมเหตุสมผลตามระดับความเสี่ยงขององค์กร ซึ่งเป็นจุดที่ Pentest เข้ามามีบทบาทสำคัญ

หน้าที่แจ้งเหตุและบทลงโทษต้องแยกเงื่อนไข

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

• มาตรา 83 กำหนดค่าปรับทางปกครองไม่เกิน 3 ล้านบาทสำหรับผู้ควบคุมข้อมูลที่ฝ่าฝืนหน้าที่ที่ระบุ รวมถึงมาตรา 37
• มาตรา 84 กำหนดไม่เกิน 5 ล้านบาทสำหรับการฝ่าฝืนเกี่ยวกับข้อมูลตามมาตรา 26 ตามเงื่อนไขที่ระบุ ไม่ใช่ค่าปรับอัตโนมัติของทุกเหตุรั่วไหล
• การไม่ปฏิบัติตามหน้าที่ DPO ที่กฎหมายกำหนดมีบทปรับตามมาตรา 82 หรือ 85 ตามบทบาท ต้องตรวจว่าเข้าเงื่อนไขแต่งตั้งหรือไม่
• มาตรา 79 แยกความผิดเกี่ยวกับข้อมูลตามมาตรา 26: กรณีที่น่าจะก่อความเสียหายตามวรรคแรกมีโทษไม่เกิน 6 เดือน/500,000 บาท; กรณีแสวงหาประโยชน์โดยมิชอบตามวรรคสองไม่เกิน 1 ปี/1 ล้านบาท หรือทั้งจำทั้งปรับ ไม่ใช่ทุกการละเมิดมีโทษอาญาเหมือนกัน
• ความรับผิดทางแพ่งตามมาตรา 77–78 มีองค์ประกอบและข้อยกเว้น ศาลอาจกำหนดค่าสินไหมเพื่อการลงโทษเพิ่มไม่เกินสองเท่าของค่าสินไหมที่แท้จริง

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

ข้อมูลอ่อนไหว (Sensitive Data) มาตรา 26 — โทษหนักกว่า

มาตรา 26 กำหนดข้อมูลอ่อนไหว ได้แก่ ข้อมูลเชื้อชาติ ความคิดเห็นทางการเมือง ศาสนา พฤติกรรมทางเพศ ประวัติอาชญากรรม ข้อมูลสุขภาพ ข้อมูลพันธุกรรม ข้อมูลชีวมิติ (Biometric Data) และข้อมูลสหภาพแรงงาน [1]

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

ทำไม Pentest คือหลักฐานประกอบอย่างหนึ่ง

เมื่อ PDPA กำหนดให้ต้องมี “มาตรการที่เหมาะสม” คำถามคือ: องค์กรจะพิสูจน์ได้อย่างไรว่ามีมาตรการเพียงพอ?

Pentest ช่วยสร้างหลักฐานเฉพาะระบบ ช่วงเวลา และขอบเขตที่ทดสอบได้ เช่น:

1. เป็นหลักฐานเชิงประจักษ์ — รายงาน Pentest แสดงว่าองค์กรได้ทดสอบระบบจริงกับเทคนิคการโจมตีจริง
2. แสดงความ Proactive — พิสูจน์ว่าองค์กรไม่ได้รอให้เกิดเหตุก่อนแล้วค่อยแก้ไข
3. ตรวจ Technical Controls ตาม scope — เช่น Access Control และ Encryption โดยระบุส่วนที่ไม่ได้ทดสอบด้วย
4. เชื่อมกับแผนความเสี่ยง — พิจารณาวิธีทดสอบให้ตรงมาตรฐานที่องค์กรใช้ ไม่เหมารวม ISO 27001, PCI DSS และ SOC 2 ว่ากำหนดวิธีหรือความถี่เหมือนกัน
5. สร้างหลักฐานเป็นลายลักษณ์อักษร — รายงาน Pentest เก็บเป็นหลักฐานได้เมื่อต้องแสดงต่อ PDPC

ขั้นตอน: จาก Pentest สู่หลักฐานความสอดคล้อง PDPA

ขั้นตอนที่ 1: ทำ Pentest อย่างครอบคลุม

ทดสอบทุกระบบที่มีการประมวลผลข้อมูลส่วนบุคคล ได้แก่ Web Application, API, Mobile App, Network Infrastructure และระบบ Cloud โดยใช้บริการ Pentest จากผู้เชี่ยวชาญ

ขั้นตอนที่ 2: แก้ไขช่องโหว่ (Remediation)

ดำเนินการแก้ไขช่องโหว่ที่พบตามระดับความรุนแรง (Critical → High → Medium → Low) และทำ Re-test เพื่อยืนยันว่าแก้ไขสำเร็จ

ขั้นตอนที่ 3: เก็บรายงานเป็นหลักฐาน

จัดเก็บรายงาน Pentest ฉบับเต็ม รายงาน Remediation และรายงาน Re-test อย่างเป็นระบบ พร้อมระบุวันที่ ขอบเขต และผลลัพธ์ เพื่อใช้เป็นหลักฐานแสดงต่อ PDPC หากถูกร้องเรียนหรือตรวจสอบ

ขั้นตอนที่ 4: ทำซ้ำเป็นประจำ

มาตรา 37(1) กำหนดให้ทบทวนมาตรการเมื่อจำเป็นหรือเทคโนโลยีเปลี่ยนแปลง ไม่ได้กำหนด annual Pentest โดยตรง คำแนะนำของบรรณาธิการ: วางรอบทดสอบตามความเสี่ยง ความสำคัญของระบบ การเปลี่ยนแปลง และข้อกำหนดรายภาคส่วน พร้อมงบแก้ไขและตรวจซ้ำตามข้อตกลง

ประเมินความพร้อมด้าน PDPA ขององค์กร

ใช้ เครื่องมือเตรียม scope ตามองค์กร ของ ITSL เพื่อรวบรวมข้อมูลระบบก่อนหารือมาตรการที่เหมาะสม และอ่านข้อกำหนด PDPA แยกต่างหาก เครื่องมือนี้ไม่ใช่การรับรองความพร้อมหรือการปฏิบัติตาม PDPA

---

แหล่งอ้างอิง

1. ราชกิจจานุเบกษา, “พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562,” 2019. ราชกิจจานุเบกษา — ตัวบทฉบับเต็ม
2. DLA Piper, “Data protection laws in Thailand,” 2025. https://www.dlapiperdataprotection.com/index.html?t=law&c=TH
3. DFDL, “Thailand: First Administrative Fine for PDPA Violation,” 2024. https://www.dfdl.com/insights/legal-and-tax-updates/thailand-first-administrative-fine-for-pdpa-violation
4. JD Supra / DLA Piper, “Thailand: PDPA Crackdown 2025: Are You Next?,” 2025. https://www.jdsupra.com/legalnews/thailand-pdpa-crackdown-2025-are-you-9467047
5. Tilleke & Gibbins, “Landmark Fine Imposed under Thailand’s Personal Data Protection Act,” 2024. https://www.tilleke.com/insights/landmark-fine-imposed-under-thailands-personal-data-protection-act

ข้อมูลทั่วไป ไม่ใช่คำปรึกษากฎหมาย ผล Pentest ไม่รับรอง compliance หรือยกเว้นความรับผิดขององค์กร