SCT

กำลังเตรียมประสบการณ์ดิจิทัล

PDPA สำหรับทีมพัฒนาซอฟต์แวร์: ทำระบบให้ถูกกฎหมายคุ้มครองข้อมูลส่วนบุคคล

พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) บังคับใช้เต็มรูปแบบตั้งแต่ปี 2565 และ สคส. กำลังบังคับใช้เข้มข้นขึ้นทุกปี บทความนี้แปลงข้อกฎหมายเป็นแนวปฏิบัติสำหรับนักพัฒนา ตั้งแต่ฐานทางกฎหมาย การขอความยินยอม ไปจนถึงการแจ้งเหตุข้อมูลรั่วภายใน 72 ชั่วโมง

พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) บังคับใช้เต็มรูปแบบตั้งแต่ปี 2565 และ สคส. กำลังบังคับใช้เข้มข้นขึ้นทุกปี บทความนี้แปลงข้อกฎหมายเป็นแนวปฏิบัติสำหรับนักพัฒนา ตั้งแต่ฐานทางกฎหมาย การขอความยินยอม ไปจนถึงการแจ้งเหตุข้อมูลรั่วภายใน 72 ชั่วโมง

PDPA คืออะไร และเกี่ยวอะไรกับนักพัฒนา

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) มีผลบังคับใช้เต็มรูปแบบตั้งแต่ 1 มิถุนายน 2565 กำกับดูแลโดยสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส. หรือ PDPC) ครอบคลุมการเก็บ ใช้ และเปิดเผยข้อมูลส่วนบุคคล โดยมีโทษทางปกครองสูงสุด 3 ล้านบาท และโทษอาญาสำหรับข้อมูลอ่อนไหว รวมถึงช่วงปี 2568-2569 สคส. ได้เพิ่มการตรวจสอบและรับเรื่องร้องเรียนเชิงรุกมากขึ้นอย่างเห็นได้ชัด

สำหรับนักพัฒนา ทุกระบบที่มีการสมัครสมาชิก ฟอร์มติดต่อ ระบบ CRM หรือแม้แต่ Log ที่เก็บ IP Address ล้วนเข้าข่ายประมวลผลข้อมูลส่วนบุคคลทั้งสิ้น การออกแบบระบบให้สอดคล้อง PDPA ตั้งแต่ต้น (Privacy by Design) ถูกกว่าการตามแก้ทีหลังเสมอ

รู้จักฐานทางกฎหมาย: ไม่ใช่ทุกอย่างต้องขอ Consent

ความเข้าใจผิดที่พบบ่อยที่สุดคือคิดว่า PDPA บังคับให้ขอความยินยอมทุกกรณี ความจริงกฎหมายกำหนดฐานการประมวลผล (Lawful Basis) ไว้หลายฐาน เช่น ฐานสัญญา (จำเป็นต่อการให้บริการที่ลูกค้าสั่ง เช่น ที่อยู่จัดส่งสินค้า), ฐานหน้าที่ตามกฎหมาย (เช่น เก็บข้อมูลตามกฎหมายบัญชี) และฐานประโยชน์อันชอบธรรม ซึ่งไม่ต้องขอความยินยอมเพิ่ม

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

ภาพประกอบเนื้อหาหมวดความปลอดภัย
ภาพประกอบเนื้อหาหมวดความปลอดภัย

เก็บเท่าที่จำเป็น: หลัก Data Minimization ในทางปฏิบัติ

หลักการสำคัญของ PDPA คือเก็บข้อมูลเท่าที่จำเป็นต่อวัตถุประสงค์ที่แจ้งไว้ ก่อนเพิ่มฟิลด์ใด ๆ ในฟอร์ม ให้ทีมถามว่าใช้ทำอะไร ถ้าตอบไม่ได้ก็ตัดออก เช่น ระบบสมัครรับข่าวสารต้องการแค่อีเมล ไม่จำเป็นต้องขอเลขบัตรประชาชนหรือวันเกิด และควรระวังเป็นพิเศษกับข้อมูลอ่อนไหวตามมาตรา 26 เช่น ข้อมูลสุขภาพ ศาสนา และข้อมูลชีวภาพ ซึ่งมีเงื่อนไขเข้มกว่ามาก

กำหนดระยะเวลาเก็บรักษา (Retention Period) ให้ชัดเจนและบังคับใช้ในระบบจริง เช่น ลบหรือทำให้เป็นนิรนาม (Anonymize) ข้อมูลผู้สมัครงานที่ไม่ผ่านหลัง 1 ปี รวมถึงจัดทำบันทึกรายการประมวลผล (Records of Processing Activities) ซึ่งเป็นเอกสารที่กฎหมายกำหนดให้องค์กรต้องมี

สิทธิของเจ้าของข้อมูล: ฟีเจอร์ที่ระบบต้องรองรับ

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

องค์กรควรกำหนดช่องทางรับคำขอใช้สิทธิ (DSAR) และตอบสนองภายในกรอบเวลาที่กฎหมายกำหนด โดยทั่วไปคือไม่เกิน 30 วัน ทีมพัฒนาควรซ้อมจริงว่าถ้ามีคำขอลบข้อมูลเข้ามาวันนี้ ต้องแตะกี่ระบบ ใช้เวลาเท่าไร เพราะหลายองค์กรพบว่าข้อมูลลูกค้ากระจายอยู่ในที่ที่ไม่มีใครจำได้

ภาพประกอบเสริมของบทความนี้
ภาพประกอบเสริมของบทความนี้

มาตรการความปลอดภัยและการแจ้งเหตุข้อมูลรั่ว

กฎหมายกำหนดให้ผู้ควบคุมข้อมูลจัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม ครอบคลุมการควบคุมการเข้าถึง การเข้ารหัสข้อมูลสำคัญ และการบันทึกการใช้งาน แนวปฏิบัติขั้นต่ำสำหรับทีมพัฒนา ได้แก่ เข้ารหัสข้อมูลทั้งตอนส่ง (TLS) และตอนจัดเก็บ, จำกัดสิทธิ์เข้าถึงฐานข้อมูล Production ตามหลัก Least Privilege และไม่นำข้อมูลจริงไปใช้ใน Environment ทดสอบโดยไม่ทำ Masking

เมื่อเกิดเหตุละเมิดข้อมูล ผู้ควบคุมข้อมูลต้องแจ้ง สคส. ภายใน 72 ชั่วโมงนับแต่ทราบเหตุ เท่าที่สามารถกระทำได้ และหากมีความเสี่ยงสูงต่อเจ้าของข้อมูลก็ต้องแจ้งเจ้าของข้อมูลด้วย ทีมจึงควรมี Incident Response Plan ที่ระบุชัดว่าใครประเมินเหตุ ใครแจ้งหน่วยงาน และเก็บหลักฐานอย่างไร พร้อมซ้อมแผนอย่างน้อยปีละครั้ง

Checklist เริ่มต้นสำหรับทีมพัฒนา

สรุปเป็นรายการตรวจสอบที่เริ่มได้ทันที: (1) ทำ Data Inventory ว่าระบบเก็บข้อมูลส่วนบุคคลอะไร ที่ไหน ด้วยฐานกฎหมายใด (2) จัดทำ Privacy Notice ภาษาเข้าใจง่ายแจ้ง ณ จุดเก็บข้อมูล (3) ตรวจระบบ Consent ให้แยกเป็นรายวัตถุประสงค์และถอนได้ (4) กำหนดและบังคับใช้ Retention Policy (5) เตรียมกระบวนการรองรับสิทธิเจ้าของข้อมูล (6) ทบทวนสัญญากับผู้ประมวลผลภายนอก เช่น ผู้ให้บริการคลาวด์ ให้มีข้อตกลงการประมวลผลข้อมูล (DPA)

องค์กรที่เข้าเงื่อนไขตามกฎหมาย เช่น มีการประมวลผลข้อมูลจำนวนมากหรือติดตามพฤติกรรมเป็นประจำ ต้องแต่งตั้งเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) ทั้งนี้ควรติดตามประกาศและแนวปฏิบัติฉบับใหม่จากเว็บไซต์ สคส. (pdpc.or.th) อย่างสม่ำเสมอ เพราะกฎหมายลำดับรองยังทยอยออกต่อเนื่อง

สิ่งที่ควรจำ

  • PDPA คืออะไร และเกี่ยวอะไรกับนักพัฒนา
  • รู้จักฐานทางกฎหมาย: ไม่ใช่ทุกอย่างต้องขอ Consent
  • เก็บเท่าที่จำเป็น: หลัก Data Minimization ในทางปฏิบัติ
แหล่งอ้างอิงเรียบเรียงจาก สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส. / PDPC) — อ่านเอกสารต้นฉบับ
มีคำถามเพิ่มเติมเกี่ยวกับบทความนี้? เขียนหาเราได้ที่ info@smart-cyber-tech.com

บทความอื่นที่เกี่ยวข้อง

เรียนรู้ต่อเนื่อง

เร่งความเร็วเว็บด้วย Core Web Vitals: คู่มือเริ่มต้นสำหรับทีมพัฒนา เว็บ

เร่งความเร็วเว็บด้วย Core Web Vitals: คู่มือเริ่มต้นสำหรับทีมพัฒนา

เว็บที่โหลดช้าเพียง 1 วินาทีอาจทำให้ Conversion ลดลงอย่างมีนัยสำคัญ บทความนี้สรุปแนวทางจากคอร์ส Learn Performance ของ Google web.dev อธิบายตัวชี้วัด Core Web Vitals ทั้ง LCP, INP และ CLS พร้อมเทคนิคปรับปรุงที่ทีมพัฒนาไทยนำไปใช้ได้ทันที

อ่านบทความ
OWASP Top 10 ฉบับปี 2025: ความเสี่ยงเว็บแอปที่นักพัฒนาทุกคนต้องรู้ ความปลอดภัย

OWASP Top 10 ฉบับปี 2025: ความเสี่ยงเว็บแอปที่นักพัฒนาทุกคนต้องรู้

OWASP ออก Top 10 ฉบับปี 2025 หลังจากฉบับก่อนหน้าถึง 4 ปี โดยมีการเปลี่ยนแปลงสำคัญคือความเสี่ยงด้าน Supply Chain ขึ้นมาเป็นอันดับ 3 บทความนี้สรุปสาระสำคัญของแต่ละหมวด พร้อมแนวทางป้องกันที่ทีมพัฒนานำไปปรับใช้ได้จริง

อ่านบทความ
ลดค่าใช้จ่ายคลาวด์อย่างเป็นระบบตามแนวทาง AWS Well-Architected คลาวด์

ลดค่าใช้จ่ายคลาวด์อย่างเป็นระบบตามแนวทาง AWS Well-Architected

องค์กรจำนวนมากจ่ายค่าคลาวด์เกินจำเป็น 20-30% จากทรัพยากรที่ไม่ได้ใช้และขนาดที่ใหญ่เกินงาน บทความนี้สรุปหลักการจาก Cost Optimization Pillar ของ AWS Well-Architected Framework ตั้งแต่การมองเห็นค่าใช้จ่าย การเลือกโมเดลราคา ไปจนถึงการสร้างวัฒนธรรม FinOps ในทีม

อ่านบทความ

อยากให้ทีมเราช่วยนำไปใช้จริง?

ตั้งแต่ประเมินระบบปัจจุบัน วางแผน จนถึงลงมือพัฒนา — คุยกับเราได้โดยไม่มีค่าใช้จ่าย

ปรึกษาทีมของเรา