PDPA มาตรา 37: มาตรการรักษาความปลอดภัยทางเทคนิคที่กฎหมายกำหนดจริงๆ คืออะไร?

พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล (PDPA / Personal Data Protection Act) บังคับใช้เต็มรูปแบบมาตั้งแต่ 1 มิถุนายน 2565 องค์กรส่วนใหญ่รู้ว่าต้องปฏิบัติตาม แต่มีไม่กี่รายที่เข้าใจจริง ๆ ว่ามาตรา 37 ต้องการอะไรจากฝั่ง มาตรการรักษาความปลอดภัยทางเทคนิค แล้วต้องทำอะไรถึงจะพิสูจน์ได้ว่าปฏิบัติตามกฎหมายแล้ว

บทความนี้จะพาไปดูว่ามาตรา 37 แปลงเป็น technical controls อะไรได้บ้าง Penetration Testing เกี่ยวข้องกับ PDPA ตรงไหน และถ้าไม่ปฏิบัติตามจะโดนอะไร

มาตรา 37 เขียนไว้ว่าอย่างไร

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

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

• ความอ่อนไหวของข้อมูลส่วนบุคคลที่ประมวลผล
• จำนวนเจ้าของข้อมูลที่ได้รับผลกระทบ
• ความเสียหายที่อาจเกิดจากการรั่วไหล
• ระดับเทคโนโลยีความปลอดภัยปัจจุบัน (state of the art)
• ต้นทุนในการดำเนินการ

ภาษากฎหมายที่ยืดหยุ่นแบบนี้มีทั้งข้อดีและข้อเสีย ข้อดีคือองค์กรเลือกแนวทางของตัวเองได้ แต่ข้อเสียคือไม่มี checklist สำเร็จรูปที่ทำตามแล้วรับประกันว่า comply

แปลงมาตรา 37 ให้เป็น Technical Controls

แม้ PDPA จะไม่ระบุเทคโนโลยีตายตัว แต่จากแนวทางของคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (คปส. / PDPC) และ case การบังคับใช้ที่ผ่านมา พอสรุปได้ว่ามาตรการเหล่านี้ถือเป็นมาตรฐานขั้นต่ำ:

1. Access Controls

สิ่งที่คาดหวัง:

• Multi-factor authentication (MFA) สำหรับระบบที่เข้าถึงข้อมูลส่วนบุคคล
• Role-based access control (RBAC): ให้พนักงานเข้าถึงได้เฉพาะข้อมูลที่จำเป็นต่องานของตัวเองเท่านั้น
• Privileged access management: สิทธิ์ระดับ admin และการเข้าถึงฐานข้อมูลต้องถูก log และจำกัดอย่างเข้มงวด
• ทบทวนสิทธิ์เป็นประจำ: ตรวจสอบทุกไตรมาสว่าใครมีสิทธิ์เข้าถึงอะไรบ้าง ยังจำเป็นอยู่ไหม

ช่องโหว่ที่มักพบจากการทำ Penetration Testing:

• ช่องโหว่ IDOR (Insecure Direct Object Reference) — แค่เปลี่ยน URL parameter ก็ดูข้อมูลส่วนบุคคลของคนอื่นได้
• API endpoint ที่คืนข้อมูลมากเกินกว่าที่ user คนนั้นควรเห็น
• หน้า admin panel ที่เข้าถึงได้โดยไม่ต้อง authenticate ให้ถูกต้อง

2. Encryption

สิ่งที่คาดหวัง:

• Data at rest: ข้อมูลส่วนบุคคลที่เก็บในฐานข้อมูล, backup และ file system ต้องเข้ารหัส (AES-256 หรือเทียบเท่า)
• Data in transit: การสื่อสารทั้งหมดที่เกี่ยวข้องกับข้อมูลส่วนบุคคลต้องใช้ TLS 1.2 ขึ้นไป
• Key management: เก็บ encryption key แยกจากข้อมูลที่เข้ารหัส, rotate เป็นประจำ และจำกัดคนที่เข้าถึง key ได้

ช่องโหว่ที่พบบ่อย:

• ฐานข้อมูลเก็บข้อมูลส่วนบุคคลแบบ plaintext
• API ภายในองค์กรสื่อสารผ่าน HTTP (ไม่เข้ารหัส) ภายในเครือข่ายองค์กร
• ไฟล์ backup เก็บโดยไม่เข้ารหัส
• แอปมือถือเก็บ token หรือข้อมูลส่วนบุคคลใน local storage แบบไม่มีการป้องกัน

3. การประเมินความปลอดภัยอย่างสม่ำเสมอ

สิ่งที่คาดหวัง: ส่วนนี้คือจุดที่ Penetration Testing เข้ามาช่วยพิสูจน์ PDPA compliance โดยตรง:

• Vulnerability Assessment: สแกนหาช่องโหว่ที่รู้จักในระบบที่ประมวลผลข้อมูลส่วนบุคคลเป็นประจำ
• Penetration Testing: ให้ผู้เชี่ยวชาญทดสอบจริงว่าช่องโหว่ที่พบ exploit ได้จริงหรือเปล่า สามารถเข้าถึงข้อมูลส่วนบุคคลได้ไหม
• Configuration Review: ตรวจว่า security configuration ตรงตามมาตรฐาน hardening หรือไม่

ทำไม Penetration Testing ถึงสำคัญต่อ PDPA:

Vulnerability Assessment บอกได้ว่า "มีจุดอ่อนที่อาจเป็นปัญหา" แต่ Penetration Testing ไปไกลกว่านั้น — พิสูจน์ให้เห็นว่าจุดอ่อนนั้นใช้เข้าถึงข้อมูลส่วนบุคคลได้จริงหรือเปล่า ในบริบทของ PDPA ความแตกต่างตรงนี้สำคัญมาก เพราะกฎหมายพูดถึงการป้องกัน "การเข้าถึงข้อมูลส่วนบุคคลโดยไม่ได้รับอนุญาต" ไม่ใช่แค่การมีช่องโหว่อยู่ในระบบ

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

4. Data Protection Impact Assessment (DPIA)

สิ่งที่คาดหวัง:

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

5. Logging and Monitoring

สิ่งที่คาดหวัง:

• Audit log ทุกครั้งที่มีการเข้าถึงข้อมูลส่วนบุคคล — บันทึกว่าใคร เข้าถึงอะไร เมื่อไหร่ จากที่ไหน
• Anomaly detection: มีระบบตรวจจับพฤติกรรมการเข้าถึงที่ผิดปกติ
• Log retention: เก็บ log นานพอสำหรับการสอบสวนกรณีข้อมูลรั่วไหล (อย่างน้อย 12 เดือนเป็น best practice)
• Log integrity: ป้องกันไม่ให้แก้ไขหรือลบ log ได้

ช่องโหว่ที่พบบ่อย:

• ไม่มี log สำหรับ database query ที่ดึงข้อมูลส่วนบุคคล
• Log บันทึกแค่ว่าทำ action อะไร แต่ไม่บอกว่าเข้าถึงข้อมูลอะไร
• ไม่มี alert เมื่อมีการ export ข้อมูลจำนวนมาก หรือ query pattern ผิดปกติ

6. Incident Response และ Breach Notification

สิ่งที่มาตรา 37(4) กำหนด:

เมื่อเกิดเหตุละเมิดข้อมูลส่วนบุคคล ผู้ควบคุมข้อมูลต้อง:

1. แจ้ง คปส. ภายใน 72 ชั่วโมง นับจากทราบเหตุ
2. แจ้งเจ้าของข้อมูลโดยไม่ชักช้า หากเหตุละเมิดมีแนวโน้มจะก่อให้เกิดความเสี่ยงสูงต่อสิทธิและเสรีภาพ
3. การแจ้งเตือนต้องระบุ:
   • ลักษณะของเหตุละเมิด
   • ข้อมูลติดต่อ DPO หรือผู้ที่ได้รับมอบหมาย
   • ผลกระทบที่อาจเกิดขึ้น
   • มาตรการที่ดำเนินการหรือเสนอให้ดำเนินการเพื่อแก้ไขเหตุละเมิด

ในทางปฏิบัติ: องค์กรต้องมีแผน Incident Response ที่พร้อมดำเนินการได้ทันทีภายใน 72 ชั่วโมง นั่นแปลว่าต้องเตรียมสิ่งเหล่านี้ไว้ล่วงหน้า:

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

บทลงโทษ PDPA: โดนจริงเท่าไหร่

PDPA มีบทลงโทษ 3 ประเภท:

โทษปรับทางปกครอง (มาตรา 84)

ระดับการละเมิด	โทษปรับสูงสุด	ตัวอย่าง
ระดับที่ 1	฿1,000,000	ไม่แต่งตั้ง DPO, ไม่จัดทำบันทึกกิจกรรมการประมวลผล (ROPA), ไม่แจ้งเหตุละเมิด
ระดับที่ 2	฿5,000,000 ต่อการละเมิด	เก็บ/ประมวลผลข้อมูลโดยไม่มีฐานกฎหมาย, มาตรการรักษาความปลอดภัยไม่เพียงพอ, ส่งข้อมูลข้ามประเทศโดยไม่ได้รับอนุญาต

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

โทษทางอาญา (หมวด 7 ส่วนที่ 2)

• จำคุกสูงสุด 1 ปี และ/หรือ ปรับสูงสุด ฿1,000,000 สำหรับการนำข้อมูลส่วนบุคคลไปใช้หรือเปิดเผยโดยมิชอบจนเกิดความเสียหาย

ความรับผิดทางแพ่ง (มาตรา 78)

• ค่าเสียหายจริง: ชดเชยตามความเสียหายที่เจ้าของข้อมูลได้รับจริง
• ค่าเสียหายเชิงลงโทษ: ศาลสั่งได้สูงสุด 2 เท่าของค่าเสียหายจริง — และค่าเสียหายจริงไม่มีเพดาน

ตัวอย่างการบังคับใช้จริง

ในปี 2024 คปส. สั่งปรับรวม ฿7,000,000 จากการละเมิด PDPA หลายรายการ ยืนยันชัดเจนว่าการบังคับใช้ไม่ได้มีไว้โชว์ และค่าปรับทบต้นข้ามหลายรายการได้จริง

Penetration Testing ช่วยเรื่อง PDPA ได้อย่างไร

ต้องทดสอบอะไรบ้าง

เมื่อทำ Penetration Testing เพื่อรองรับ PDPA ควรเน้นทดสอบจุดเหล่านี้:

1. เส้นทางเข้าถึงข้อมูลส่วนบุคคล: ผู้โจมตีเข้าถึงข้อมูลส่วนบุคคลผ่าน web application, API หรือ network intrusion ได้ไหม?

2. Access Control ทำงานจริงไหม: user ที่มี Role A ข้ามไปดูข้อมูลของ Role B ได้หรือเปล่า? ลูกค้า A เห็นข้อมูลของลูกค้า B ได้ไหม?

3. ข้อมูลระหว่างส่งปลอดภัยไหม: ข้อมูลส่วนบุคคลถูกเข้ารหัสระหว่างส่งหรือเปล่า? ดักจับได้ไหม?

4. ข้อมูลที่เก็บปลอดภัยไหม: ข้อมูลส่วนบุคคลเข้ารหัส at rest หรือยัง? Backup ได้รับการปกป้องหรือเปล่า?

5. Authentication แข็งแรงพอไหม: bypass authentication ได้หรือเปล่า? รหัสผ่านเก็บอย่างปลอดภัยไหม? MFA บังคับใช้จริงไหม?

6. Third-party integration: API ที่เชื่อมกับพาร์ทเนอร์หรือ vendor มีจุดที่ข้อมูลส่วนบุคคลรั่วไหลได้ไหม?

รายงานต้องมีอะไรบ้าง

ถ้าจะใช้รายงาน Penetration Testing เป็นหลักฐาน PDPA compliance ควรมีอย่างน้อย:

• Scope statement: ระบุว่าทดสอบระบบไหนบ้างที่ประมวลผลข้อมูลส่วนบุคคล
• Methodology: ใช้มาตรฐานอะไร (OWASP, PTES)
• Findings ที่ map กับประเภทข้อมูล: ระบุชัดว่า finding ไหนอาจทำให้เข้าถึงข้อมูลส่วนบุคคลโดยไม่ได้รับอนุญาต
• PDPA compliance mapping: finding แต่ละตัวเกี่ยวข้องกับข้อกำหนดมาตรา 37 ตรงไหน
• หลักฐานการแก้ไข: ยืนยันว่าปัญหาที่พบถูกแก้ไขแล้ว
• Residual risk assessment: ความเสี่ยงที่ยังเหลือหลังแก้ไขมีอะไรบ้าง

ความถี่ในการทดสอบ

PDPA ไม่ได้ระบุว่าต้องทดสอบบ่อยแค่ไหน แต่ตามมาตรฐาน "มาตรการที่เหมาะสม" ควรทดสอบ:

• อย่างน้อยปีละครั้ง สำหรับระบบที่ประมวลผลข้อมูลส่วนบุคคล
• หลังมีการเปลี่ยนแปลงสำคัญ เช่น ปล่อยฟีเจอร์ใหม่ เปลี่ยน infrastructure หรือเพิ่ม third-party integration
• หลังเกิด security incident เพื่อยืนยันว่า root cause ถูกแก้ไขแล้วจริง
• ก่อนเปิดตัวระบบใหม่ ที่จะประมวลผลข้อมูลส่วนบุคคล

วางโปรแกรม Security ตาม PDPA ทำอย่างไร

Phase 1: ประเมินสถานะปัจจุบัน (เดือนที่ 1-2)

1. Data mapping: ระบุให้ได้ว่าระบบไหนบ้างที่ประมวลผลข้อมูลส่วนบุคคล
2. Risk assessment: จัดลำดับระบบตามความอ่อนไหวของข้อมูลและปริมาณ
3. Gap analysis: เทียบมาตรการรักษาความปลอดภัยที่มีอยู่กับข้อกำหนดมาตรา 37
4. Vulnerability Assessment: สแกนระบบที่เกี่ยวข้องกับข้อมูลส่วนบุคคลทั้งหมด

Phase 2: Penetration Testing (เดือนที่ 2-3)

5. กำหนด scope: เริ่มจากระบบความเสี่ยงสูงสุดก่อน (แอปที่ลูกค้าใช้, ฐานข้อมูลที่มีข้อมูลอ่อนไหว)
6. Penetration Testing: ให้ผู้เชี่ยวชาญทดสอบเจาะตามเส้นทางเข้าถึงข้อมูลส่วนบุคคล
7. Remediation: แก้ไขช่องโหว่ที่พบ พร้อมคำแนะนำระดับ developer
8. Verification Retest: ทดสอบซ้ำเพื่อยืนยันว่าแก้ได้จริง

Phase 3: โปรแกรมต่อเนื่อง (Continuous)

9. Vulnerability scan รายไตรมาส: สแกนจับช่องโหว่ใหม่ ๆ ที่เกิดขึ้น
10. Penetration Testing ประจำปี: ทดสอบเจาะเต็มรูปแบบโดยผู้เชี่ยวชาญ
11. Continuous monitoring: Logging, alerting และ anomaly detection
12. Access review รายไตรมาส: ตรวจสอบว่าสิทธิ์ที่ให้ไว้ยังเหมาะสมอยู่ไหม
13. ซ้อม Incident Response: ทดสอบว่าทีมแจ้งเตือนและตอบสนองได้ทันภายใน 72 ชั่วโมงจริงหรือเปล่า

ข้อผิดพลาดที่เจอบ่อย

1. คิดว่า PDPA เป็นเรื่องของฝ่ายกฎหมายอย่างเดียว: แบบฟอร์มขอ consent ไม่ได้ปกป้องข้อมูล สิ่งที่ปกป้องจริง ๆ คือ technical controls

2. ทดสอบแค่รอบนอก (perimeter): Data breach ส่วนใหญ่มาจาก insider หรือ account ภายในที่ถูก compromise ไม่ใช่แฮกเกอร์เจาะ firewall จากข้างนอก

3. มองข้าม API: แอปสมัยนี้เปิดเผยข้อมูลส่วนบุคคลผ่าน API มากกว่าผ่านหน้าเว็บ ถ้าไม่ทดสอบ API security ก็เหมือนล็อกประตูหน้าแต่เปิดประตูหลังทิ้งไว้

4. ไม่มีแผน Breach Notification: 72 ชั่วโมงสั้นกว่าที่คิด ถ้าไม่มีแผนเตรียมไว้ล่วงหน้า ไม่มีทางทำทัน

5. คิดว่าขึ้น Cloud แล้วปลอดภัยเอง: Cloud provider ดูแลแค่ infrastructure แต่ความปลอดภัยของแอปพลิเคชัน configuration และ access control ยังเป็นหน้าที่ขององค์กร การทำ Secure Code Review และ Vulnerability Assessment สำหรับระบบบน Cloud จึงยังขาดไม่ได้

สรุป

1. มาตรา 37 กำหนดให้มี "มาตรการรักษาความปลอดภัยที่เหมาะสม" วัดจากความอ่อนไหวของข้อมูล จำนวนเจ้าของข้อมูล และความเสียหายที่อาจเกิดหากข้อมูลรั่ว

2. Penetration Testing เป็นหลักฐานที่หนักแน่นที่สุด ว่า technical controls ทำงานได้จริง ไม่ใช่แค่มีอยู่บนกระดาษ

3. บทลงโทษมีจริงและทบต้นได้: สูงสุด ฿5M ต่อการละเมิด ยังไม่รวมโทษอาญาและค่าเสียหายทางแพ่งที่ศาลคูณได้อีก 2 เท่า

4. แจ้งเหตุละเมิดภายใน 72 ชั่วโมง ต้องเตรียมแผน Incident Response ไว้ล่วงหน้า สร้างแผนตอนเกิดเหตุไม่ทัน

5. Penetration Testing ปีละครั้งเป็นขั้นต่ำ ถ้ามีการเปลี่ยนแปลงสำคัญ ควรทดสอบเพิ่มเติมด้วย

---

อยากรู้ว่าองค์กรของคุณพร้อมแค่ไหนตามมาตรา 37? ดูรายละเอียดที่หน้า PDPA Compliance หรือติดต่อ Reconix เพื่อปรึกษาผู้เชี่ยวชาญ

แหล่งอ้างอิงกฎระเบียบและมาตรฐาน

• พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (ฉบับเต็ม)
• เว็บไซต์ คปส. (สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล)
• OWASP Web Security Testing Guide (WSTG)
• Penetration Testing Execution Standard (PTES)
• IBM Cost of a Data Breach Report 2024

---

บริการที่เกี่ยวข้องจาก Reconix

• Penetration Testing — ทดสอบเจาะระบบเพื่อพิสูจน์ว่ามาตรการตามมาตรา 37 ใช้ได้จริง พร้อมรายงานที่ map กับข้อกำหนด PDPA
• Vulnerability Assessment — สแกนช่องโหว่เป็นประจำสำหรับระบบที่ประมวลผลข้อมูลส่วนบุคคล จัดลำดับตามความรุนแรง
• Secure Code Review — ตรวจโค้ดแอปที่จัดการข้อมูลส่วนบุคคล หาช่องโหว่ตาม OWASP Top 10 ก่อน deploy
• Cybersecurity Consulting — ที่ปรึกษา PDPA Compliance ช่วยทำ Gap Assessment และวางโปรแกรม security ตามมาตรา 37