สารบัญ
- ทำไมเรื่องนี้ต้องรีบอ่านก่อน 14 กันยายน
- ข้อเท็จจริงของกฎใหม่ที่ธุรกิจต้องรู้
- สิทธิขอเข้าถึงข้อมูลส่วนบุคคลกำลังกลายเป็น “งานจริง”
- ผลกระทบต่อธุรกิจในประเทศไทย
- อีกเรื่องที่องค์กรใหญ่ต้องจับตา: BCR
- สิ่งที่ควรทำต่อ
- มุมมองผู้เชี่ยวชาญ
- แหล่งอ้างอิง
ทำไมเรื่องนี้ต้องรีบอ่านก่อน 14 กันยายน
สิทธิขอเข้าถึงข้อมูลส่วนบุคคล กำลังเปลี่ยนจากเรื่องที่หลายองค์กรคิดว่า “มีแบบฟอร์มไว้ก็น่าจะพอ” ไปเป็นกระบวนการที่ต้องมีขั้นตอนและหลักฐานชัดเจน โดย PDPC ออกประกาศใหม่ในเดือนกรกฎาคม 2569 และประกาศดังกล่าวมีผลใช้บังคับวันที่ 14 กันยายน 2569.
เรื่องนี้สำคัญเพราะคำขอจากลูกค้า พนักงาน หรือเจ้าของข้อมูลไม่ได้มาเป็นระเบียบเสมอไป บางครั้งมาในอีเมล บางครั้งผ่านเจ้าหน้าที่หน้าสาขา หรือผ่านตัวแทนที่อ้างว่าได้รับอนุญาตจากเจ้าของข้อมูล ธุรกิจจึงไม่ได้มีโจทย์แค่ “รู้ว่าต้องให้ข้อมูล” แต่ต้องตอบให้ได้ว่า ใครขอ ขออะไร ตรวจสอบอย่างไร เปิดอะไรได้บ้าง และใครเป็นคนอนุมัติ
ข้อเท็จจริงของกฎใหม่ที่ธุรกิจต้องรู้
ประกาศของ PDPC ครอบคลุมขั้นตอนการขอเข้าถึงหรือขอสำเนาข้อมูลส่วนบุคคล รวมถึงการขอทราบแหล่งที่มาของข้อมูลที่องค์กรได้มาโดยไม่ได้อาศัยความยินยอมโดยตรงจากเจ้าของข้อมูล นอกจากนี้ยังเกี่ยวข้องกับข้อมูลที่กำหนดไว้ใน Privacy Notice และ Record of Processing Activities หรือ ROPA ตามเงื่อนไขที่ประกาศกำหนด.
สิ่งที่องค์กรต้องเตรียมไม่ใช่แค่แบบฟอร์มคำขอ เพราะประกาศกำหนดเรื่องกระบวนการรับคำขอ การตรวจสอบตัวตน วิธีจัดการกรณีคำขอไม่ครบ และการเก็บบันทึกย้อนหลังด้วย
จุดที่คนทำงานควรจำให้แม่นมีดังนี้
องค์กรต้องมีอย่างน้อยช่องทางรับคำขอแบบติดต่อด้วยตนเองและทางไปรษณีย์ และสามารถเพิ่มช่องทางอิเล็กทรอนิกส์ได้ โดยคำขอต้องมีข้อมูลและเอกสารประกอบที่ใช้ตรวจสอบตัวตนตามที่กำหนด.
เมื่อรับคำขอแล้ว องค์กรต้องตรวจสอบคำขอและตัวตน หากข้อมูลไม่ครบต้องแจ้งให้ผู้ร้องแก้ไขให้เรียบร้อย
เมื่อคำขอครบถ้วนและใช้ได้แล้ว ผู้ควบคุมข้อมูลต้องดำเนินการภายใน 30 วัน และสามารถขยายเวลาได้อีกไม่เกิน 30 วัน เมื่อมีเหตุจำเป็น เช่น คำขอมีข้อมูลจำนวนมากหรือมีความซับซ้อน โดยต้องแจ้งผู้ร้องตามเงื่อนไขของประกาศ.
การปฏิเสธก็ไม่ใช่สิทธิที่องค์กรจะใช้เมื่อไรก็ได้ ต้องมีเหตุรองรับตามกฎหมายหรือเหตุอื่นที่ประกาศกำหนด เช่น กระทบสิทธิของผู้อื่น ข้อมูลที่ได้รับความคุ้มครอง หรือคำขอที่ไม่มีมูลหรือสร้างภาระอย่างไม่สมเหตุสมผล.
ส่วนค่าใช้จ่าย หลักทั่วไปคือการขอเข้าถึงข้อมูลไม่ควรถูกเรียกเก็บเงินโดยอัตโนมัติ แต่ประกาศเปิดทางให้เรียกเก็บในบางกรณี เช่น รูปแบบพิเศษ ค่าใช้จ่ายในการจัดส่ง หรือคำขอซ้ำ ๆ ที่สร้างภาระเพิ่มเติมตามหลักเกณฑ์ที่กำหนด.
และอีกเรื่องที่ไม่ควรมองข้ามคือ การเก็บบันทึกคำขอและผลการดำเนินการอย่างน้อย 2 ปี.
สิทธิขอเข้าถึงข้อมูลส่วนบุคคลกำลังกลายเป็น “งานจริง”
ตรงนี้คือประเด็นที่ธุรกิจไทยควรสนใจมากกว่าตัวหนังสือในประกาศ
ก่อนหน้านี้หลายองค์กรวาง PDPA ไว้กับฝ่ายกฎหมายหรือ DPO แล้วจบเหมือนเป็นโครงการเอกสารหนึ่งครั้ง แต่ สิทธิขอเข้าถึงข้อมูลส่วนบุคคล ทำให้เห็นชัดว่าเรื่องนี้เป็นงานปฏิบัติการเต็มตัว
ลองนึกภาพง่าย ๆ ว่าลูกค้ารายหนึ่งส่งคำขอเข้ามา
พนักงานหน้าบ้านต้องรู้ว่าจะส่งเรื่องให้ใคร
คนรับผิดชอบต้องรู้ว่าจะตรวจตัวตนอย่างไร
IT ต้องรู้ว่าข้อมูลอยู่ในระบบไหน
ฝ่ายกฎหมายต้องช่วยประเมินว่ามีข้อมูลของคนอื่นปะปนอยู่หรือไม่
ฝ่ายที่ถือข้อมูลต้องดึงข้อมูลให้ถูกชุด
และองค์กรต้องเก็บหลักฐานว่าใครตรวจอะไร และตอบอย่างไร
นี่จึงไม่ใช่งานของ DPO คนเดียวแล้ว
มันมีลักษณะคล้าย SLA ภายในองค์กรมากขึ้น เพราะทุกคำขอมี “นาฬิกา” ของมันเอง และความผิดพลาดหนึ่งจุดอาจลากไปทั้งกระบวนการ
ที่น่าสนใจอีกเรื่องคือ ประกาศไม่ได้ทำให้ข้อมูลทุกอย่างที่อยู่ในระบบต้องถูกส่งออกไปให้ผู้ร้องแบบไม่คัดกรอง องค์กรยังต้องพิจารณาผลกระทบต่อสิทธิของบุคคลอื่น รวมถึงข้อมูลที่ได้รับความคุ้มครอง เช่น เรื่องความลับทางการค้า สิทธิในทรัพย์สินทางปัญญา หรือข้อมูลที่กฎหมายจำกัดการเปิดเผย.
พูดง่าย ๆ คือ การให้ข้อมูลก็มีความเสี่ยง และการไม่ให้ข้อมูลก็มีความเสี่ยง องค์กรจึงต้องมีคนตัดสินใจและมีเหตุผลรองรับทั้งสองทาง
ผลกระทบต่อธุรกิจในประเทศไทย
สำหรับ SME ผลกระทบที่ชัดที่สุดอาจไม่ใช่ต้นทุนด้านกฎหมาย แต่เป็นต้นทุนจากการไม่มีเจ้าของกระบวนการ
บริษัทขนาดเล็กจำนวนไม่น้อยเก็บข้อมูลลูกค้าไว้หลายที่ ทั้ง Google Workspace, CRM, โปรแกรมบัญชี, LINE, แบบฟอร์มออนไลน์ และไฟล์ Excel ของพนักงาน บางแห่งยังมีข้อมูลเก่าที่สร้างไว้ก่อนเริ่มโครงการ PDPA อย่างจริงจังด้วย เมื่อมีคำขอเข้าถึงข้อมูล สิ่งที่ยากจึงไม่ใช่การ “ตอบอีเมล” แต่เป็นการหาว่าข้อมูลของบุคคลนั้นกระจายอยู่ที่ไหนบ้าง
หากไม่มี Data Map หรืออย่างน้อยไม่มีรายการระบบสำคัญที่ใช้เก็บข้อมูล ทีมงานอาจตอบไม่ครบ หรือดึงข้อมูลผิดคนได้
สำหรับองค์กรขนาดใหญ่ ความเสี่ยงจะยิ่งซับซ้อน เพราะหนึ่งคำขออาจเกี่ยวข้องกับหลายหน่วยงาน หลายระบบ และหลายประเทศ โดยเฉพาะบริษัทที่มี Shared Service หรือระบบ Cloud จากต่างประเทศ การตอบคำขอจึงต้องเชื่อมทั้ง PDPA, Cybersecurity, IT Operations, Vendor Management และการกำกับดูแลข้อมูล
อีกจุดที่สำคัญคือเรื่อง “บุคคลที่สาม” หากข้อมูลลูกค้ารายหนึ่งอยู่ในเอกสารเดียวกับข้อมูลของพนักงาน ลูกค้าคนอื่น หรือคู่ค้า การส่งสำเนาออกไปโดยไม่คัดกรองอาจเปิดข้อมูลของคนอื่นโดยไม่ตั้งใจได้ ดังนั้นระบบต้องมีทั้งขั้นตอนตรวจเอกสารและผู้มีอำนาจอนุมัติ ไม่ใช่ให้พนักงานค้นไฟล์แล้วกด Send
ในเชิงธุรกิจ เรื่องนี้ยังสะท้อนการเปลี่ยนมุมมองสำคัญของ PDPA จาก Policy Compliance ไปสู่ Operational Compliance
องค์กรที่มี Privacy Policy สวยมาก แต่เมื่อมีคำขอจริงกลับไม่รู้ว่าจะเริ่มตรงไหน ก็ยังมีช่องโหว่อยู่ดี
ในทางกลับกัน SME ที่ไม่มีระบบใหญ่โต แต่กำหนดเจ้าของเรื่องชัด มีแบบฟอร์ม มีขั้นตอน Verify มีรายการระบบที่ต้องค้น และมี Log ทุกครั้ง ก็อาจจัดการความเสี่ยงได้ดีกว่าองค์กรที่มีเอกสารเป็นตั้งแต่ไม่มีใครหยิบมาใช้
ดังนั้นสิ่งที่ธุรกิจควรถามตัวเองไม่ใช่แค่ “เรามี PDPA Policy หรือยัง”
แต่ควรถามว่า
“ถ้าพรุ่งนี้มีคนขอข้อมูล แล้วเข้ามาทางอีเมลตอนบ่ายสาม เรารู้ไหมว่าจะเริ่มจากใคร?”
ถ้าคำตอบยังเป็น “เดี๋ยวค่อยถามกัน” นั่นคือช่องโหว่เชิงปฏิบัติการแล้ว
อีกเรื่องที่องค์กรใหญ่ต้องจับตา: BCR
ในเวลาเดียวกัน PDPC ก็มีกรอบที่ชัดขึ้นสำหรับ Binding Corporate Rules หรือ BCR ซึ่งเกี่ยวกับการโอนข้อมูลส่วนบุคคลข้ามประเทศภายในกลุ่มบริษัท
กฎ BCR ที่ลงวันที่ 29 กันยายน 2568 เปิดทางให้ทั้ง BCR สำหรับผู้ควบคุมข้อมูลและผู้ประมวลผลข้อมูล โดยผู้สมัครต้องมีสถานประกอบการในไทยและมีผู้รับผิดชอบในประเทศ การตรวจเอกสารเบื้องต้นใช้เวลา 15 วัน และการพิจารณาเนื้อหากำหนดกรอบไม่เกิน 180 วันตามหลักเกณฑ์ที่เกี่ยวข้อง ขณะเดียวกันไม่มีค่าธรรมเนียมสำหรับการยื่นคำขอ.
สำหรับบริษัทข้ามชาติ นี่คืออีกเส้นหนึ่งของงาน PDPA ที่ควรแยกออกจากการจัดการคำขอใช้สิทธิทั่วไป
พูดแบบธุรกิจคือ
SME ควรรีบทำระบบรับและตอบคำขอให้เดินได้ก่อน
ส่วนองค์กรขนาดใหญ่ที่โอนข้อมูลข้ามประเทศเป็นประจำ ควรเปิด Data Transfer Map แล้วถามต่อว่าโครงสร้าง BCR เหมาะกว่าทางเลือกเดิมหรือไม่.
สิ่งที่ควรทำต่อ
- ตั้งเจ้าของกระบวนการให้ชัด
ระบุว่าใครรับคำขอ ใครตรวจตัวตน ใครดึงข้อมูล ใครตรวจเรื่องบุคคลที่สาม และใครเป็นผู้อนุมัติคำตอบ - ทำแบบฟอร์มและช่องทางรับคำขอให้พร้อม
อย่าปล่อยให้พนักงานตีความคำขอเองทุกครั้ง กำหนดช่องทางกลางและวิธีส่งต่อภายในองค์กร - ทำรายการระบบที่เก็บข้อมูลบุคคลอย่างน้อยในระดับใช้งานจริง
ไม่ต้องรอสร้างระบบ Data Governance มูลค่าหลายล้านบาท แค่รู้ก่อนว่าข้อมูลสำคัญอยู่ใน CRM, HR, Accounting, Email, Cloud และระบบใดบ้าง ก็ลดความเสี่ยงได้มาก - สร้างตัวจับเวลาและหลักฐาน
บันทึกวันรับคำขอ วันตรวจสอบความครบถ้วน ผู้รับผิดชอบ ผลการพิจารณา และวันตอบ เพื่อพิสูจน์ได้ว่ากระบวนการเดินอย่างไร - แยก SME กับ Enterprise Action Plan
สำหรับ SME ให้โฟกัสกระบวนการ Access Request ก่อน ส่วนองค์กรที่มีการโอนข้อมูลข้ามประเทศเป็นประจำควรประเมิน BCR เพิ่ม.
แหล่งอ้างอิง
Herbert Smith Freehills Kramer รายงานเกี่ยวกับประกาศใหม่ของ PDPC และผลใช้บังคับวันที่ 14 กันยายน 2569 พร้อมสรุปขั้นตอนการรับคำขอ การตรวจตัวตน กรอบเวลา เหตุปฏิเสธ ค่าธรรมเนียม และการเก็บบันทึก.
อ่านต้นฉบับ Herbert Smith Freehills Kramer
Baker McKenzie ระบุว่าประกาศถูกเผยแพร่ในราชกิจจานุเบกษาเมื่อ 16 กรกฎาคม 2569 และจะมีผลในวันที่ 14 กันยายน 2569 พร้อมรายละเอียดเรื่องช่องทางรับคำขอ การตรวจสอบตัวตน 30 วัน การขยายเวลา ค่าธรรมเนียม และการเก็บบันทึกอย่างน้อย 2 ปี.
อ่านต้นฉบับ Baker McKenzie
LawPlus Ltd. สรุปกฎ PDPC เรื่องการตรวจสอบและรับรอง BCR ซึ่งมีผลกับการโอนข้อมูลข้ามประเทศภายในกลุ่มบริษัท รวมถึงกรอบการตรวจเอกสาร 15 วัน การพิจารณาเนื้อหา 180 วัน และการไม่มีค่าธรรมเนียมยื่นคำขอ.
อ่านต้นฉบับ LawPlus Ltd.
Internal Links:
อ่านต่อเรื่องการเชื่อม PDPA เข้ากับ Data Governance และระบบ AI ได้ที่บทความของ Tech Law Now เรื่อง PDPA และ AI Governance
สำหรับแนวคิดการจัดการสิทธิของเจ้าของข้อมูลและเอกสารกระบวนการ สามารถอ้างอิงแนวทางใน ชุดแนวปฏิบัติบริหารจัดการความยินยอม PDPA ฉบับองค์กร ของ Kooru
YMYL Disclaimer
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย
หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
