เช็กลิสต์ทำตาม PDPA สำหรับธุรกิจไทย (ปี 2026)

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

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

PDPA กำหนดอะไรบ้าง

PDPA กำหนดให้ท่านรู้ว่ามีข้อมูลส่วนบุคคลอะไรอยู่ มีฐานทางกฎหมายในการประมวลผล มีมาตรการรักษาความปลอดภัยที่เหมาะสม ตอบสนองสิทธิของเจ้าของข้อมูลภายในกรอบเวลาที่กฎหมายกำหนด และแจ้งเหตุละเมิดที่เข้าเงื่อนไขต่อ สคส. ภายใน 72 ชั่วโมง ทุกข้อด้านล่างคือรายละเอียดการนำห้าข้อนี้ไปปฏิบัติ

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

ขั้นที่ 1 — ทำแผนที่ข้อมูลส่วนบุคคลที่มีอยู่

ทำ Data Inventory ก่อนอย่างอื่นทั้งหมด ว่าเก็บข้อมูลส่วนบุคคลอะไร เก็บไว้ที่ไหน ใครเข้าถึงได้ และเก็บนานแค่ไหน ท่านปกป้อง ลบ หรือส่งมอบข้อมูลที่ยังไม่เคยทำแผนที่ไม่ได้ และภาระหน้าที่ทุกข้อที่ตามมาขึ้นอยู่กับการมีบันทึกนี้

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

บันทึกผลลัพธ์เป็น Record of Processing Activities (RoPA) มาตรา 39 กำหนดให้ผู้ควบคุมข้อมูลต้องจัดทำ และเป็นเอกสารแรกที่ถูกขอในการตรวจสอบทุกครั้ง

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

ขั้นที่ 2 — กำหนดฐานทางกฎหมายของทุกกิจกรรม

ทุกกิจกรรมการประมวลผลต้องมีฐานทางกฎหมายที่บันทึกไว้ ความยินยอมเป็นเพียงหนึ่งในหลายฐาน และมักเป็นตัวเลือกที่อ่อนที่สุดเพราะถอนได้ หากใช้ความยินยอม ต้องให้โดยอิสระ เฉพาะเจาะจง ได้รับข้อมูลครบ และมีการบันทึก การติ๊กช่องไว้ล่วงหน้าไม่ถือเป็นความยินยอมตาม PDPA

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

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

ขั้นที่ 3 — วางมาตรการทางเทคนิค

มาตรา 37 กำหนดให้มี "มาตรการรักษาความปลอดภัยที่เหมาะสม" ในทางปฏิบัติ สคส. และผู้ตรวจสอบดู 6 อย่าง คือ การให้สิทธิ์เท่าที่จำเป็น การเข้ารหัสทั้งระหว่างส่งและขณะจัดเก็บ การทำ Audit Log การสำรองข้อมูลที่ทดสอบแล้ว การจัดการอัปเดตแพตช์ และแผนรับมือเหตุการณ์ที่เป็นลายลักษณ์อักษร ทั้งหมดนี้คือการควบคุมด้าน IT มาตรฐาน ไม่ใช่เครื่องมือเฉพาะทางด้าน Compliance

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

กรอบเวลาแจ้งเหตุ 72 ชั่วโมงตามมาตรา 37(4) คือข้อกำหนดที่ทำให้องค์กรตกม้าตายบ่อยที่สุด 72 ชั่วโมงไม่พอสำหรับสร้างความสามารถในการตรวจจับหลังเกิดเหตุ ท่านต้องมี Logging และระบบแจ้งเตือนอยู่ก่อนแล้ว พร้อมคู่มือที่ระบุว่าใครเป็นคนตัดสินใจ ใครเป็นคนแจ้ง และต้องเก็บรักษาหลักฐานอะไร หากตอนนี้ยังตอบไม่ได้ว่า "มีใครเข้าถึงข้อมูลนี้โดยมิชอบหรือไม่" นั่นคือช่องว่างแรกที่ต้องปิด ก่อนทุกข้อในรายการนี้

ขั้นที่ 4 — ตอบสนองคำขอของเจ้าของข้อมูลให้ได้

เจ้าของข้อมูลขอเข้าถึง แก้ไข ลบ ระงับ โอนย้าย และคัดค้านได้ ท่านต้องตอบภายใน 30 วัน บททดสอบจริงคือท่านหาข้อมูลทุกชุดของคน ๆ หนึ่งจากทุกระบบได้หรือไม่ ซึ่งเป็นไปได้ก็ต่อเมื่อขั้นที่ 1 ทำไว้อย่างถูกต้อง

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

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

จุดที่บริษัทส่วนใหญ่มักพลาด

ความผิดพลาดที่พบบ่อยไม่ได้ซับซ้อน จากงานประเมินของเรา พบหกเรื่องเดิมซ้ำ ๆ คือ การใช้บัญชีผู้ดูแลร่วมกัน ไม่มี Audit Log ข้อมูลสำรองไม่ได้เข้ารหัส ผู้ให้บริการภายนอกมีสิทธิ์เข้าถึงค้างไว้โดยไม่มีการจัดการ ไม่มีช่องทางถอนความยินยอมที่ใช้งานได้ และไม่มีวิธีตอบสนองภายใน 30 วัน

ทุกข้อแก้ได้ด้วยการควบคุมด้าน IT มาตรฐาน และไม่มีข้อไหนต้องใช้ซอฟต์แวร์ Compliance เฉพาะทาง สิ่งที่ต้องมีคือคนที่รับผิดชอบงานนี้จริง และการมองว่าเป็นวินัยในการดำเนินงานที่มีรอบทบทวน ไม่ใช่โครงการที่จบไปแล้วตอนประกาศนโยบาย

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