พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล (PDPA) มีผลบังคับใช้เต็มรูปแบบมาตั้งแต่เดือนมิถุนายน 2565 แต่จากสถิติการบังคับใช้ในปี 2568 ที่ผ่านมา พบว่าหลายองค์กรยังมีช่องโหว่สำคัญที่อาจนำไปสู่บทลงโทษทั้งทางแพ่งและทางปกครอง การตรวจสอบความพร้อมอย่างเป็นระบบจึงไม่ใช่ทางเลือก แต่เป็นสิ่งจำเป็น
บทความนี้รวบรวม PDPA Checklist 15 ข้อที่ครอบคลุมทุกด้านที่สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) ให้ความสำคัญ พร้อมวิเคราะห์ช่องโหว่ที่พบบ่อยที่สุดในองค์กรไทย
ส่วนที่ 1: โครงสร้างและธรรมาภิบาล (Governance)
ข้อ 1 — แต่งตั้ง DPO หรือผู้รับผิดชอบด้านข้อมูลส่วนบุคคล
องค์กรที่อยู่ในเกณฑ์ต้องแต่งตั้งเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) ตามมาตรา 41 เช่น หน่วยงานรัฐ องค์กรที่ประมวลผลข้อมูลอ่อนไหวปริมาณมาก หรือองค์กรที่ติดตามพฤติกรรมบุคคลอย่างเป็นระบบ ต้องมีการแต่งตั้งอย่างเป็นทางการ แม้ไม่อยู่ในเกณฑ์บังคับ ก็ควรกำหนดผู้รับผิดชอบหลักด้าน PDPA ที่ชัดเจน
ข้อนี้ดูเหมือนง่ายแต่ที่เจอบ่อยคือ แต่งตั้ง DPO เป็นลายลักษณ์อักษรแล้ว แต่ไม่มีอำนาจหน้าที่จริง หรือไม่ได้รับทรัพยากรสนับสนุน
ข้อ 2 — จัดทำนโยบายคุ้มครองข้อมูลส่วนบุคคล (Privacy Policy)
ต้องมี Privacy Policy ที่เป็นปัจจุบัน ครอบคลุมทุกจุดที่เก็บรวบรวมข้อมูล ทั้งเว็บไซต์ แอปพลิเคชัน แบบฟอร์มกระดาษ และช่องทาง offline ภาษาที่ใช้ต้องเข้าใจง่าย ไม่ใช่แค่คัดลอกจากเทมเพลตภาษาอังกฤษแล้วแปล
ข้อ 3 — กำหนดบทบาทผู้ควบคุมและผู้ประมวลผลข้อมูล
ต้องระบุชัดเจนว่าองค์กรทำหน้าที่เป็น Data Controller หรือ Data Processor ในแต่ละกิจกรรมการประมวลผล และมีการจัดทำสัญญาประมวลผลข้อมูล (Data Processing Agreement — DPA) กับผู้ให้บริการภายนอกทุกราย
ส่วนที่ 2: ฐานกฎหมายและ Consent (Legal Basis)
ข้อ 4 — ระบุฐานกฎหมายสำหรับทุกกิจกรรมการประมวลผล
PDPA กำหนดฐานกฎหมาย 6 ประเภท ได้แก่ ความยินยอม (Consent) สัญญา (Contract) หน้าที่ตามกฎหมาย (Legal Obligation) ประโยชน์สำคัญต่อชีวิต (Vital Interest) ภารกิจของรัฐ (Public Task) และประโยชน์โดยชอบด้วยกฎหมาย (Legitimate Interest) ต้องมีการจัดทำ Lawful Basis Assessment สำหรับทุกกิจกรรม
ช่องโหว่ที่พบบ่อย: ใช้ Consent เป็นฐานกฎหมายสำหรับทุกอย่าง ทั้งที่หลายกรณีควรใช้ฐานสัญญาหรือ Legitimate Interest แทน
ข้อ 5 — ระบบจัดการ Consent ที่ตรวจสอบได้
หากใช้ความยินยอมเป็นฐานกฎหมาย ต้องมีระบบบันทึกที่พิสูจน์ได้ว่าเจ้าของข้อมูลให้ความยินยอมเมื่อใด ด้วยวิธีใด สำหรับวัตถุประสงค์อะไร และสามารถถอนความยินยอมได้ง่ายเท่ากับการให้ ระบบต้องเก็บ Consent Log แบบ append-only ที่แก้ไขย้อนหลังไม่ได้
ข้อ 6 — แยก Consent ตามวัตถุประสงค์อย่างชัดเจน
ห้ามรวมความยินยอมหลายวัตถุประสงค์ไว้ในช่อง checkbox เดียว เจ้าของข้อมูลต้องสามารถเลือกยินยอมเป็นรายวัตถุประสงค์ได้
ส่วนที่ 3: บันทึกกิจกรรมและ Data Inventory
ข้อ 7 — จัดทำบันทึกรายการกิจกรรมการประมวลผล (RoPA)
มาตรา 39 กำหนดให้ทั้ง Data Controller และ Data Processor ต้องจัดทำ Record of Processing Activities (RoPA) ที่ระบุประเภทข้อมูล วัตถุประสงค์ ฐานกฎหมาย ผู้รับข้อมูล ระยะเวลาการเก็บ และมาตรการรักษาความปลอดภัย
ข้อ 8 — จัดทำ Data Inventory หรือ Data Mapping
ต้องทราบว่าข้อมูลส่วนบุคคลอยู่ที่ไหนบ้าง ไหลจากจุดใดไปจุดใด ใครเข้าถึงได้ และเก็บไว้นานเท่าใด Data Mapping เป็นรากฐานของทุกกิจกรรม PDPA ที่เหลือ
สิ่งที่พบบ่อยคือ องค์กรจัดทำ Data Inventory ครั้งเดียวแล้วไม่เคยกลับมาอัปเดต พอมีระบบหรือกระบวนการใหม่ ข้อมูลก็ล้าสมัยจนใช้ประโยชน์ไม่ได้
ส่วนที่ 4: สิทธิเจ้าของข้อมูลและ DSR
ข้อ 9 — กระบวนการรองรับคำขอใช้สิทธิ (DSR Process)
ต้องมีกระบวนการรองรับคำขอใช้สิทธิทั้ง 6 ประเภท ได้แก่ สิทธิในการเข้าถึง แก้ไข ลบ ระงับ โอนย้าย และคัดค้าน โดยต้องตอบกลับภายใน 30 วันนับแต่ได้รับคำขอ
ข้อ 10 — ช่องทางรับคำขอ DSR ที่เข้าถึงได้ง่าย
ต้องจัดให้มีช่องทางที่เจ้าของข้อมูลสามารถยื่นคำขอใช้สิทธิได้โดยสะดวก เช่น เว็บฟอร์ม อีเมล หรือระบบออนไลน์ ไม่ใช่ซ่อนอยู่ลึกจนหาไม่เจอ
ส่วนที่ 5: ความปลอดภัยของข้อมูล
ข้อ 11 — มาตรการรักษาความปลอดภัยที่เหมาะสม
มาตรา 37(1) กำหนดให้มีมาตรการรักษาความปลอดภัยที่เหมาะสม ทั้งเชิงเทคนิค (เช่น encryption, access control, logging) และเชิงองค์กร (เช่น นโยบาย การฝึกอบรม การตรวจสอบ) ต้องประเมินความเสี่ยงและปรับมาตรการให้สอดคล้อง
ข้อ 12 — แผนรับมือเหตุละเมิดข้อมูล (Incident Response Plan)
ต้องมีแผนตอบสนองต่อเหตุ Data Breach ที่พร้อมปฏิบัติได้ทันที รวมถึงกระบวนการแจ้งเตือน สคส. ภายใน 72 ชั่วโมง และแจ้งเจ้าของข้อมูลในกรณีที่มีความเสี่ยงสูง
ปัญหาที่พบซ้ำแล้วซ้ำเล่า: มีแผนบนกระดาษแต่ไม่เคยซ้อมจริง พอเกิดเหตุจริงจึงดำเนินการไม่ทันเวลา
ส่วนที่ 6: การส่งข้อมูลและบุคคลที่สาม
ข้อ 13 — ข้อตกลงกับผู้ประมวลผลข้อมูลภายนอก
ต้องมี Data Processing Agreement (DPA) กับทุก vendor ที่ประมวลผลข้อมูลส่วนบุคคลแทนองค์กร ระบุขอบเขตหน้าที่ มาตรการรักษาความปลอดภัย สิทธิในการตรวจสอบ และเงื่อนไขการลบข้อมูลเมื่อสิ้นสุดสัญญา
ข้อ 14 — การส่งข้อมูลไปต่างประเทศ (Cross-border Transfer)
หากมีการส่งข้อมูลส่วนบุคคลไปยังต่างประเทศ ต้องมั่นใจว่าประเทศปลายทางมีมาตรฐานการคุ้มครองข้อมูลที่เพียงพอ หรือมีมาตรการป้องกันที่เหมาะสม เช่น Binding Corporate Rules (BCRs) หรือ Standard Contractual Clauses (SCCs)
ส่วนที่ 7: การฝึกอบรมและวัฒนธรรมองค์กร
ข้อ 15 — ฝึกอบรมพนักงานทุกระดับอย่างสม่ำเสมอ
PDPA Compliance ไม่ใช่ความรับผิดชอบของฝ่าย IT หรือ Legal เพียงฝ่ายเดียว พนักงานทุกคนที่สัมผัสข้อมูลส่วนบุคคลต้องได้รับการฝึกอบรมที่เหมาะสมกับบทบาท มีการทดสอบความเข้าใจ และจัดอบรมทบทวนเป็นประจำอย่างน้อยปีละ 1 ครั้ง
ข้อนี้เป็นจุดอ่อนของหลายองค์กร โดยเฉพาะองค์กรที่จัดอบรมครั้งเดียวตอนกฎหมายมีผลบังคับใช้แล้วหยุดไป พนักงานใหม่จึงไม่เคยได้รับการอบรมเลย
สิ่งที่ สคส. ให้ความสำคัญเป็นพิเศษ
จากแนวปฏิบัติและการบังคับใช้ที่ผ่านมา สคส. ให้ความสำคัญเป็นพิเศษกับ 3 ประเด็นหลัก
เรื่อง หลักฐานที่ตรวจสอบได้ (Accountability) สคส. ไม่ได้ถามแค่ว่ามีนโยบายหรือเปล่า แต่ถามว่าพิสูจน์ได้ไหมว่าปฏิบัติตามจริง Consent Log, RoPA, DPA, บันทึกการอบรม, Incident Report ทุกอย่างต้องเป็นระบบ
ในส่วนของ สิทธิเจ้าของข้อมูล นั้น สคส. คาดหวังว่าองค์กรต้องตอบสนองคำขอใช้สิทธิได้จริงภายในกรอบเวลาที่กฎหมายกำหนด ไม่ใช่รับคำขอแล้วปล่อยค้าง
อีกเรื่องที่ สคส. เข้มงวดมากคือ การแจ้งเตือนเหตุละเมิดภายใน 72 ชั่วโมง องค์กรที่ไม่มีกระบวนการตรวจจับและรายงานที่ชัดเจนจะดำเนินการไม่ทันเวลาแทบทุกครั้ง
จาก Checklist สู่การปฏิบัติจริง
การมี Checklist เป็นจุดเริ่มต้นที่ดี แต่การนำไปปฏิบัติจริงต้องการเครื่องมือที่เหมาะสม หลายองค์กรเริ่มต้นด้วย spreadsheet แล้วพบว่าไม่สามารถ scale ได้เมื่อปริมาณข้อมูลและคำขอเพิ่มขึ้น
สิ่งที่ควรมองหาในเครื่องมือ PDPA Compliance ได้แก่ ระบบที่ครอบคลุมทั้ง Consent Management, DSR Management, Data Inventory, RoPA, Breach Management และ Vendor Management ในที่เดียว มี Audit Trail ที่แก้ไขไม่ได้ และไม่เก็บข้อมูลส่วนบุคคลจริงเพื่อลดความเสี่ยง
