PDPA คืออะไร — 8 ข้อที่องค์กรต้องทำ (และข้อไหนที่ Security Tool ช่วยได้จริง)
PDPA คืออะไร องค์กรต้องทำอะไรบ้างครบทั้ง 8 ข้อ พร้อมคดีจริง JIB โดนปรับ 7 ล้านบาท และจุดที่ Security Tool ช่วยได้จริงแค่ 2 ใน 8 ข้อ ปรึกษาฟรีกับทีม zcr วันนี้
PDPA คืออะไร — 8 ข้อที่องค์กรต้องทำ (และข้อไหนที่ Security Tool ช่วยได้จริง)
วันที่ 21 สิงหาคม 2567 คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) สั่งปรับบริษัท J.I.B. Computer Group ผู้จำหน่ายสินค้าไอทีรายใหญ่ เป็นเงิน 7,000,000 บาท — นี่คือการลงโทษทางปกครองครั้งแรกภายใต้ PDPA นับตั้งแต่กฎหมายบังคับใช้เต็มรูปแบบ
ที่น่าสนใจคือค่าปรับ 7 ล้านนี้ไม่ได้มาจากข้อหาเดียว แต่แบ่งเป็น 3 ก้อน: ไม่แต่งตั้ง DPO ทั้งที่ประมวลผลข้อมูลคนกว่าแสนราย (1 ล้านบาท), มาตรการความปลอดภัยไม่เพียงพอจนข้อมูลรั่ว (3 ล้านบาท) และแจ้ง PDPC ไม่ทันภายใน 72 ชั่วโมงทั้งที่มีลูกค้าร้องเรียนเข้ามาแล้ว 23 ราย (3 ล้านบาท) — พูดง่ายๆ คือบริษัทนี้พลาดพร้อมกันหลายจุดในคราวเดียว
คำถามแรกที่มักถามกันเรื่อง PDPA คือ: "PDPA มีกี่ข้อกันแน่ ต้องทำอะไรบ้าง" บทความนี้ตอบให้ครบทั้ง 8 ข้อ — และเพราะเราขายผลิตภัณฑ์ security ไม่ใช่บริการกฎหมาย เราจะบอกตรงๆ ด้วยว่าข้อไหนที่ security tool อย่างเราช่วยได้จริง และข้อไหนที่ต่อให้ซื้อเครื่องมือดีแค่ไหนก็ช่วยไม่ได้ เพราะมันคืองานเอกสาร งานกฎหมาย และงานคน
PDPA คืออะไร แบบสั้นที่สุด
PDPA ย่อมาจาก Personal Data Protection Act หรือชื่อเต็มภาษาไทยคือพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 ประกาศในราชกิจจานุเบกษาตั้งแต่ปี 2562 แต่เลื่อนบังคับใช้มาหลายรอบช่วงโควิด จนบังคับใช้เต็มรูปแบบจริงวันที่ 1 มิถุนายน 2565
หน่วยงานที่ดูแลคือคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) โดยมีสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลเป็นฝ่ายเลขานุการ ทำหน้าที่ทั้งออกประกาศย่อย ตรวจสอบ และสั่งปรับ
บทลงโทษมีสามทาง ไม่ใช่แค่ค่าปรับทางปกครองอย่างเดียว — โทษทางปกครองสูงสุด 5,000,000 บาทต่อกรรม (กรณีประมวลผลข้อมูลอ่อนไหวโดยไม่มีฐานกฎหมายรองรับ), โทษทางอาญาจำคุกสูงสุด 1 ปีและ/หรือปรับสูงสุด 1,000,000 บาท (กรณีมีเจตนาทุจริตหรือหาประโยชน์โดยมิชอบ) และโทษทางแพ่งที่ให้ชดใช้ค่าเสียหายจริงบวกค่าเสียหายเชิงลงโทษได้อีกสูงสุด 2 เท่า — สามทางนี้แยกกันเด็ดขาด องค์กรหนึ่งโดนพร้อมกันได้ทั้งสามทาง
กฎหมายฉบับนี้คุ้มครอง "ข้อมูลส่วนบุคคล" ของคนที่ระบุตัวตนได้ ไม่ว่าจะเป็นลูกค้า พนักงาน หรือคู่ค้า แทบทุกองค์กรที่เก็บชื่อ อีเมล เบอร์โทร หรือ IP address ของใครสักคนก็เข้าข่ายต้องปฏิบัติตาม ไม่ใช่แค่บริษัทไอทีหรือธุรกิจขนาดใหญ่
8 ข้อที่ PDPA กำหนดให้องค์กรต้องทำ
เรียงตามมาตราในกฎหมาย พร้อมบอกตรงๆ ท้ายแต่ละข้อว่า zcr ช่วยได้หรือไม่
1. มีฐานทางกฎหมายและจัดการ consent ให้ถูกต้อง
ก่อนเก็บหรือใช้ข้อมูลส่วนบุคคลของใคร ต้องมี "ฐานทางกฎหมาย" รองรับเสมอ — อาจเป็นความยินยอม (consent) ตามมาตรา 24 หรือฐานอื่นอย่างการปฏิบัติตามสัญญา ประโยชน์อันชอบด้วยกฎหมาย หรือการปฏิบัติตามกฎหมายอื่น ส่วนข้อมูลอ่อนไหว เช่น ศาสนา เชื้อชาติ ประวัติสุขภาพ ต้องขอความยินยอมโดยชัดแจ้งตามมาตรา 26 ซึ่งเข้มกว่าข้อมูลทั่วไป
ตรงนี้คือการออกแบบ consent banner, consent management platform และการเลือกฐานกฎหมายให้เหมาะกับ data flow แต่ละแบบ ซึ่งต้องอาศัยที่ปรึกษากฎหมายหรือทีม privacy โดยเฉพาะ — ไม่มีผลิตภัณฑ์ตัวไหนของ zcr ที่เกี่ยวข้องกับขั้นตอนนี้เลย
2. จัดทำ RoPA — บันทึกรายการกิจกรรมการประมวลผลข้อมูล
มาตรา 39 กำหนดให้ผู้ควบคุมข้อมูลต้องจัดทำ Record of Processing Activities (RoPA) คือบันทึกว่าองค์กรเก็บข้อมูลอะไร เก็บทำไม เก็บนานแค่ไหน แชร์ให้ใครบ้าง — เอกสารนี้เป็นสิ่งแรกที่ PDPC จะขอดูถ้ามีการตรวจสอบ
ข้อยกเว้นที่หลายคนเข้าใจผิด: PDPC ออกประกาศยกเว้นภาระ RoPA ให้ธุรกิจ SME (ฝั่งผู้ควบคุมข้อมูลมีผลบังคับใช้ตั้งแต่ 8 เมษายน 2568) แต่นี่ไม่ใช่การยกเว้น PDPA ทั้งฉบับ เป็นการยกเว้นเฉพาะข้อ RoPA ข้อเดียว เกณฑ์ SME ที่ใช้อ้างอิงคือรายได้ไม่เกิน 100 ล้านบาทต่อปีและพนักงานไม่เกิน 50 คน หรือรายได้ไม่เกิน 50 ล้านบาทและพนักงานไม่เกิน 30 คน (แตกต่างกันไปตามประเภทธุรกิจ) — และต่อให้เข้าเกณฑ์ SME แล้ว ถ้าการประมวลผลข้อมูลมีความเสี่ยงต่อสิทธิของเจ้าของข้อมูล ไม่ใช่การประมวลผลเป็นครั้งคราว หรือเกี่ยวข้องกับข้อมูลอ่อนไหวตามมาตรา 26 ก็ยังต้องทำ RoPA อยู่ดี ส่วนอีก 7 ข้อที่เหลือ SME ก็ยังต้องทำครบเหมือนองค์กรขนาดใหญ่
ข้อนี้ zcr ไม่เกี่ยว — RoPA คือเอกสารบันทึก data flow ทั้งองค์กร ไม่ใช่สิ่งที่ log management หรือ security tool จะสร้างแทนได้
3. มี Privacy Policy หรือ Privacy Notice แจ้งเจ้าของข้อมูล
มาตรา 23 กำหนดให้ต้องแจ้งเจ้าของข้อมูลก่อนหรือขณะเก็บข้อมูลว่าเก็บอะไร เพื่อวัตถุประสงค์อะไร เก็บนานแค่ไหน และเจ้าของข้อมูลมีสิทธิอะไรบ้าง — Privacy Policy บนเว็บไซต์ที่ทุกคนคุ้นเคยคือรูปแบบหนึ่งของการปฏิบัติตามข้อนี้
คนที่ควรทำเรื่องนี้คือทีมกฎหมายหรือที่ปรึกษาด้าน privacy ไม่ใช่ zcr — การเขียน Privacy Policy ให้ครบถ้วนตามกฎหมายและตรงกับ data flow จริงขององค์กรเป็นงานร่างเอกสาร ไม่ใช่งานด้าน security monitoring
4. มีกลไกรองรับสิทธิของเจ้าของข้อมูล
มาตรา 30–36 ให้สิทธิเจ้าของข้อมูลหลายอย่าง เช่น สิทธิขอเข้าถึงข้อมูล สิทธิขอแก้ไขให้ถูกต้อง สิทธิขอลบ สิทธิขอให้โอนย้ายข้อมูล และสิทธิถอนความยินยอมเมื่อไหร่ก็ได้ องค์กรต้องมีช่องทางและกระบวนการรองรับคำขอเหล่านี้จริง ไม่ใช่แค่มีสิทธิในทางทฤษฎี
เรื่องนี้อยู่นอกขอบเขตผลิตภัณฑ์ของ zcr ทั้งหมด การสร้างฟอร์มรับคำขอ กระบวนการยืนยันตัวตนผู้ขอ และ workflow อนุมัติภายใน เป็นงานของระบบ CRM หรือ data governance ไม่ใช่ security monitoring
5. มีมาตรการความปลอดภัยที่เหมาะสม — ข้อที่ zcr ช่วยได้จริง
มาตรา 37(1) กำหนดให้ผู้ควบคุมข้อมูลต้องจัดให้มีมาตรการรักษาความปลอดภัยที่เหมาะสม ครอบคลุมทั้งการควบคุมการเข้าถึง (access control) การเข้ารหัสข้อมูล และการบันทึกการเข้าถึง (audit logging) — คดี JIB ที่เล่าไปตอนต้นโดนปรับ 3 ล้านบาทจากข้อนี้โดยเฉพาะ เพราะมาตรการความปลอดภัยไม่เพียงพอจนข้อมูลรั่วไหล
นี่คือจุดที่ security tool เข้ามามีบทบาทจริง:
- zcrLog เก็บ log การเข้าถึงระบบและข้อมูลแบบรวมศูนย์ พร้อม RBAC จำกัดว่าใครดู log ได้บ้าง และมี audit trail ว่าใครเข้าถึงอะไรเมื่อไหร่ — ถ้าใครถามว่า "ใครเข้าถึงฐานข้อมูลลูกค้าเมื่อคืนนี้" องค์กรต้องตอบได้ ไม่ใช่เดา บทความ PDPA กับ Log พาลงลึกเฉพาะมุมนี้ ถ้าอยากรู้ว่าเก็บ log ยังไงให้ไม่ผิดทั้ง PDPA และ พ.ร.บ.คอมฯ ไปพร้อมกัน
- zcrSIEM ใช้ AI-assisted threat hunting ช่วยนักวิเคราะห์ค้นหาพฤติกรรมเข้าถึงข้อมูลที่ผิดปกติได้เร็วขึ้น พิมพ์ประโยคภาษาธรรมชาติอย่าง "unusual access to customer database at night" แล้วให้ AI แปลงเป็น query ให้ — แต่ query ที่ได้มา นักวิเคราะห์ต้องตรวจสอบและแก้ไขได้เสมอก่อนรันจริง ไม่ใช่ปล่อยให้ AI ตัดสินใจเอง อ่านรายละเอียดฟีเจอร์นี้เพิ่มที่ AI-Assisted Threat Hunting คืออะไร
- zcrWAF ป้องกันเว็บแอปและ API ที่รับข้อมูลส่วนบุคคลจากการโจมตีกลุ่ม OWASP Top 10 เช่น SQL injection ที่มักเป็นช่องทางหลักที่แฮกเกอร์ใช้ดึงข้อมูลออกจากฐานข้อมูลลูกค้า
- zcrCTEM สแกนหา asset ที่เปิดเผยออกสู่อินเทอร์เน็ตโดยไม่ตั้งใจ เช่น ฐานข้อมูลที่ misconfigure จนเข้าถึงได้จากภายนอก ก่อนที่คนร้ายจะเจอมันก่อน
ทั้งหมดนี้คือ "มาตรการความปลอดภัยที่เหมาะสม" ตามความหมายของมาตรา 37(1) จริงๆ ไม่ใช่แค่คำโฆษณา
6. แต่งตั้ง DPO เมื่อเข้าเงื่อนไข
มาตรา 41 กำหนดให้ต้องแต่งตั้ง Data Protection Officer เมื่อกิจกรรมหลักขององค์กรคือการเฝ้าติดตามข้อมูลส่วนบุคคลหรือระบบในขนาดใหญ่ หรือกิจกรรมหลักคือการประมวลผลข้อมูลอ่อนไหวตามมาตรา 26 หรือเป็นหน่วยงานรัฐที่ PDPC กำหนด ประกาศชี้แจงเรื่องนี้มีผลบังคับใช้ตั้งแต่ 13 ธันวาคม 2566
ข้อควรระวัง: ตัวเลข "แสนราย" ที่หลายบทความอ้างเป็นเกณฑ์ "ขนาดใหญ่" นั้น จริงๆ มาจากข้อเท็จจริงเฉพาะของคดี JIB (ที่ประมวลผลข้อมูลลูกค้ากว่าแสนรายตอนโดนปรับ) ไม่ใช่ตัวเลขที่ประกาศ PDPC ระบุไว้เป็นเกณฑ์ตายตัว สิ่งที่ยืนยันได้ชัดคือ "ขนาดใหญ่" ขึ้นอยู่กับดุลยพินิจตามลักษณะกิจกรรมจริง ไม่ใช่ตัวเลขคงที่ในกฎหมาย ถ้าไม่แน่ใจว่าองค์กรเข้าเกณฑ์หรือไม่ ควรปรึกษาที่ปรึกษากฎหมายโดยตรงแทนการเดาเอง
การแต่งตั้งคนเป็นเรื่องขององค์กรและ HR ไม่ใช่สิ่งที่ software ตัวไหนแก้แทนได้ — ข้อนี้ก็เช่นกัน ไม่มีส่วนไหนที่ zcr ช่วยได้
7. มีแผนรับมือเหตุการณ์ และแจ้ง PDPC ภายใน 72 ชั่วโมง — อีกข้อที่ zcr ช่วยได้จริง
มาตรา 37(4) กำหนดให้ต้องแจ้งเหตุการละเมิดข้อมูลส่วนบุคคลต่อ PDPC โดยไม่ชักช้า และเท่าที่จะทำได้ภายใน 72 ชั่วโมงนับจากที่รู้เหตุ (มีข้อยกเว้นถ้าประเมินความเสี่ยงแล้วพบว่าไม่กระทบสิทธิเสรีภาพของเจ้าของข้อมูล และถ้าพลาดกรอบ 72 ชั่วโมงจริงๆ ต้องแจ้งโดยเร็วที่สุดไม่เกิน 15 วัน พร้อมเหตุผลประกอบ) — คดี JIB โดนปรับ 3 ล้านบาทจากข้อนี้ เพราะรู้เหตุจากลูกค้าที่ร้องเรียนเข้ามาเองถึง 23 ราย ไม่ใช่จากระบบตรวจจับของบริษัท และแจ้ง PDPC ไม่ทันกรอบเวลา
คำถามที่องค์กรส่วนใหญ่ไม่เคยถามตัวเองคือ "ถ้าข้อมูลรั่วตอนนี้ เราจะรู้ตัวภายในกี่ชั่วโมง" เพราะนาฬิกา 72 ชั่วโมงเริ่มนับตั้งแต่วินาทีที่ "รู้" ไม่ใช่ตั้งแต่วินาทีที่เกิดเหตุจริง องค์กรที่ตรวจจับช้าก็เท่ากับเผาเวลาของตัวเองไปฟรีๆ ก่อนนาฬิกาจะเริ่มเดินด้วยซ้ำ — แบบเดียวกับที่เกิดขึ้นจริงในคดี JIB
นี่คือจุดที่ automation เข้ามาช่วยได้เป็นรูปธรรม หน้าแดชบอร์ด Security Operations ของ zcrSIEM รวมจำนวนเหตุการณ์แยกตามระดับความรุนแรง เวลาเฉลี่ยกว่าจะมีคนรับเคส (MTTA) เวลาเฉลี่ยกว่าจะปิดเคสได้ (MTTR) สัดส่วนเหตุการณ์ที่อยู่ในกรอบ SLA และเวลาตั้งแต่เหตุเกิดจนระบบตรวจจับได้ (detection latency) ไว้ในหน้าเดียว — ซึ่งก็คือคำตอบของคำถามข้างต้นที่ว่า "เราจะรู้ตัวภายในกี่ชั่วโมง" ยิ่งขั้นตอนคัดกรองเบื้องต้นทำงานอัตโนมัติมากเท่าไหร่ เวลาที่เหลือของนักวิเคราะห์ก็ยิ่งไปอยู่กับการตัดสินใจว่าเหตุการณ์ไหนเป็นเรื่องจริงที่ต้องรายงาน แทนที่จะไล่เช็ค log ทีละบรรทัดด้วยมือ
ตรวจพบเร็วอย่างเดียวยังไม่พอ ต้องตอบสนองเร็วด้วย zcrSOAR ช่วยส่วนนี้ด้วย playbook ที่เริ่มต้นจาก node ประเภท Trigger เมื่อมี alert เข้ามา จากนั้น node ประเภท Action จะทำงานอัตโนมัติในขั้นตอนที่ไม่กระทบระบบจริงสูง เช่น enrich ข้อมูล IOC หรือดึง log เพิ่มเติม แต่จะมี node ประเภท Approval คั่นก่อนเสมอในขั้นตอนที่กระทบระบบจริง เช่น isolate เครื่องหรือปิด account ส่วน node ประเภท Human Task จะส่งงานให้คนตัดสินใจโดยตรงในขั้นตอนที่ต้องใช้วิจารณญาณของมนุษย์จริงๆ — สถาปัตยกรรมแบบ human-on-the-loop นี้อธิบายละเอียดไว้ที่ Agentic Automation ใน SOAR ทำงานยังไง
พูดตรงๆ ว่าองค์กรที่ยังพึ่งการตรวจสอบด้วยมือล้วนๆ แทบเป็นไปไม่ได้เลยที่จะรู้ตัวว่าถูกละเมิดข้อมูลเร็วพอจะแจ้ง PDPC ทันภายใน 72 ชั่วโมง — นาฬิกาเริ่มเดินตั้งแต่วินาทีที่รู้ ไม่ใช่วินาทีที่เกิดเหตุ
8. มีสัญญากับผู้ประมวลผลข้อมูลบุคคลภายนอก
มาตรา 40 กำหนดว่าถ้าองค์กรจ้างบุคคลภายนอกมาประมวลผลข้อมูลแทน เช่น ผู้ให้บริการ cloud, payroll outsourcing, marketing agency ต้องมีสัญญาระบุขอบเขตและมาตรการความปลอดภัยที่ผู้ประมวลผลต้องทำตาม ไม่ใช่ส่งข้อมูลออกไปเฉยๆ โดยไม่มีข้อผูกพันทางกฎหมาย
ท้ายที่สุดคือเรื่องสัญญา ซึ่งเป็นงานของทีมกฎหมายและจัดซื้อ ไม่ใช่สนามที่ zcr เล่นอยู่
สรุปตรงๆ: zcr ช่วยได้ 2 ใน 8 ข้อ ไม่ใช่ทั้งหมด
จาก 8 ข้อข้างต้น zcr ช่วยได้จริงแค่ข้อ 5 (มาตรการความปลอดภัย) และข้อ 7 (แผนรับมือเหตุการณ์และแจ้ง PDPC ทัน) ส่วนอีก 6 ข้อที่เหลือ — consent, RoPA, Privacy Policy, สิทธิเจ้าของข้อมูล, DPO, สัญญากับ vendor — เป็นงานเอกสาร งานกฎหมาย และงานตัดสินใจเชิงองค์กรที่ security tool ช่วยไม่ได้ ไม่ว่าจะโฆษณาดีแค่ไหนก็ตาม
เราเลือกพูดแบบนี้เพราะเชื่อว่าองค์กรที่กำลังหาทางทำ PDPA ให้ครบ ควรรู้ตั้งแต่ต้นว่าต้องหาที่ปรึกษากฎหมายคู่ขนานไปกับการลงทุนด้าน security ไม่ใช่คิดว่าซื้อเครื่องมือตัวเดียวแล้วจบครบทุกข้อ — 2 ข้อที่เราช่วยได้ก็บังเอิญเป็น 2 ข้อที่มีมูลค่าปรับหนักสุดในคดี JIB (รวมกัน 6 ล้านบาทจาก 7 ล้านบาททั้งหมด) ดังนั้นแม้จะเป็นแค่ 2 ใน 8 ข้อ แต่เป็น 2 ข้อที่ความเสี่ยงทางการเงินสูงสุดถ้าทำพลาด
เริ่มจากตรงไหนดี ถ้ายังไม่เคยทำอะไรเลย
ถ้าองค์กรยังไม่เคยเริ่มทำ PDPA เลยสักข้อ ลำดับที่แนะนำคือ:
- ปรึกษาที่ปรึกษากฎหมายเพื่อทำ RoPA และ Privacy Policy ก่อน เพราะสองข้อนี้เป็นฐานที่ข้ออื่นต้องอ้างอิงต่อ — ต้องรู้ว่าเก็บข้อมูลอะไรก่อน ถึงจะรู้ว่าต้องป้องกันอะไร
- ประเมินว่าเข้าเงื่อนไขต้องมี DPO หรือไม่ ถ้าไม่แน่ใจให้ถามที่ปรึกษากฎหมายตรงๆ อย่าเดาเอง
- คู่ขนานกันไป เริ่มวางมาตรการความปลอดภัยที่จับต้องได้ — access control, encryption, audit logging ให้ครบตามมาตรา 37(1)
- เตรียมแผนรับมือเหตุการณ์และระบบตรวจจับที่เร็วพอ เพราะนาฬิกา 72 ชั่วโมงไม่รอใคร
ข้อ 3 และ 4 คือจุดที่เราคุยได้เต็มที่ ลองดูแพ็กเกจ zcrSIEM, zcrLog และ zcrSOAR เพื่อดูว่าเหมาะกับขนาดองค์กรแค่ไหน
ติดต่อทีมงาน
อยากรู้ว่าองค์กรของคุณพร้อมแค่ไหนในข้อ 5 และข้อ 7 ของ PDPA ทีมงานยินดีให้คำปรึกษาฟรี ไม่มีค่าใช้จ่าย
แหล่งอ้างอิง
- สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล, GPPC Privacy Policy — ตัวอย่างการอธิบายข้อมูล วัตถุประสงค์ และระยะเวลาการเก็บรักษาสำหรับกิจกรรมประมวลผลเฉพาะ: https://gppc.pdpc.or.th/privacy-policy/ (เข้าถึง 14 กันยายน 2026)
- PDPC Portal — ข้อมูลเกี่ยวกับบทบาทผู้ควบคุม/ผู้ประมวลผลและ DPO: https://dpo.pdpc.or.th/registration (เข้าถึง 14 กันยายน 2026)
- หมายเหตุ: checklist นี้เป็นแนวทางทั่วไป ไม่ใช่คำวินิจฉัยทางกฎหมาย และแต่ละองค์กรต้องประเมินฐานกฎหมาย วัตถุประสงค์ และระยะเวลาเก็บข้อมูลของตนเอง