บทนำ
ลองนึกภาพว่าเช้าวันหนึ่งลูกค้าส่งอีเมลมาว่า
“ขอข้อมูลส่วนบุคคลทั้งหมดที่บริษัทมีเกี่ยวกับผม และ ขอทราบด้วยว่าข้อมูลบางส่วนที่ผมไม่เคยให้มาจากไหน”
คำถามที่องค์กรต้องตอบไม่ใช่แค่ “มีแบบฟอร์มให้ลูกค้ากรอกหรือยัง”
แต่ต้องตอบให้ได้ว่า ข้อมูลของลูกค้าคนนี้อยู่ที่ไหนบ้าง ใครเป็นเจ้าของข้อมูลในแต่ละระบบ ใครมีสิทธิ์ดึงข้อมูล ใครตรวจสอบก่อนส่ง และใครรับผิดชอบไม่ให้ข้อมูลของคนอื่นติดออกไป
นี่คือเหตุผลที่ประกาศหลักเกณฑ์เกี่ยวกับการเข้าถึงและขอรับสำเนาข้อมูลส่วนบุคคล พ.ศ. 2569 ซึ่งประกาศในราชกิจจานุเบกษาเมื่อ 16 กรกฎาคม 2569 และจะมีผลใช้บังคับวันที่ 14 กันยายน 2569 ควรถูกมองมากกว่าการเป็น “กฎใหม่เรื่อง 30 วัน”
ประเด็นสำคัญสำหรับธุรกิจคือ เวลาที่เหลือไม่ได้มีไว้สำหรับอ่านกฎหมายอย่างเดียว แต่มีไว้สำหรับทดสอบว่าองค์กรตอบคำขอจริงได้หรือไม่
กฎหมายใหม่กำลังทำให้กระบวนการ DSAR ชัดขึ้น
ประกาศของคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลกำหนดรายละเอียดเกี่ยวกับการใช้สิทธิในการเข้าถึงและขอสำเนาข้อมูลส่วนบุคคล รวมถึงกรณีที่เจ้าของข้อมูลต้องการทราบแหล่งที่มาของข้อมูลซึ่งตนไม่ได้ให้ความยินยอม โดยประกาศอยู่ในราชกิจจานุเบกษา เล่ม 143 ตอนพิเศษ 175 ง วันที่ 16 กรกฎาคม 2569 และกำหนดให้มีผลเมื่อพ้น 60 วันนับจากวันประกาศ หรือวันที่ 14 กันยายน 2569
เมื่อคำขอมีรายละเอียดและหลักฐานที่จำเป็นครบถ้วน รวมถึงสามารถตรวจสอบตัวตนของผู้ยื่นได้แล้ว ผู้ควบคุมข้อมูลต้องดำเนินการให้เสร็จภายใน 30 วัน และในกรณีที่มีเหตุจำเป็นสามารถขยายได้อีกไม่เกิน 30 วัน โดยต้องแจ้งเหตุผลให้เจ้าของข้อมูลทราบ
กฎยังวางรายละเอียดเกี่ยวกับกรณีเอกสารไม่ครบ การเรียกเก็บค่าใช้จ่าย การปฏิเสธคำขอ และการจัดการข้อมูลของบุคคลอื่นที่อยู่รวมกับข้อมูลของผู้ยื่นคำขอด้วย
อีกจุดที่ธุรกิจไม่ควรมองข้ามคือ การดำเนินการไม่ได้จบลงทันทีเมื่อส่งข้อมูลให้ลูกค้า เพราะองค์กรต้องเก็บรายละเอียดคำขอ เอกสาร การดำเนินการ และหลักฐานที่เกี่ยวข้องไว้เป็นเวลาอย่างน้อย 2 ปี
ดังนั้น สิ่งที่เกิดขึ้นจริงคือ PDPA กำลังขยับจากการกำหนด “สิทธิ” ไปสู่การกำหนด กระบวนการที่องค์กรต้องสามารถพิสูจน์ได้ว่าทำจริง
“DSAR ไม่ใช่แบบฟอร์มหนึ่งใบ แต่คือ การทดสอบว่าองค์กรรู้จักข้อมูลของตัวเองดีแค่ไหน”
ผลกระทบต่อธุรกิจในประเทศไทย: ปัญหาไม่ได้อยู่ที่ 30 วัน แต่อยู่ที่ “หาข้อมูลให้เจอ”
นี่คือจุดที่ผู้บริหารควรหยุดคิดสักนิด
สมมติบริษัทหนึ่งมีลูกค้า 500,000 ราย ข้อมูลของลูกค้าคนเดียวอาจไม่ได้อยู่ในฐานข้อมูลเดียว แต่อาจกระจายอยู่ใน CRM, ระบบสมาชิก, ระบบชำระเงิน, Call Center, Marketing Automation, อีเมล, ระบบร้องเรียน และระบบจัดเก็บเอกสาร
เมื่อมี DSAR เข้ามา ฝ่ายกฎหมายอาจเป็นคนรับเรื่อง แต่ไม่สามารถเดินเข้าไปในทุกระบบแล้วดึงข้อมูลออกมาเองได้
ต้องมีฝ่าย Customer Service ช่วยตรวจสอบคำขอ ฝ่าย IT ค้นข้อมูล ฝ่าย Data ช่วยรวบรวม ฝ่าย Security ตรวจช่องทางส่ง ฝ่ายกฎหมายหรือ DPO ประเมินข้อจำกัด และบางกรณีต้องมีเจ้าของระบบช่วยตัดข้อมูลของบุคคลที่สามออกก่อนส่ง
นี่ทำให้ 30 วันไม่ได้เป็น deadline ของ DPO คนเดียว แต่กลายเป็น deadline ของกระบวนการทั้งองค์กร
องค์กรที่ข้อมูลจัดระเบียบดีจะได้เปรียบ เพราะสามารถระบุตัวบุคคล ค้นข้อมูล และรวบรวมผลลัพธ์ได้เร็ว
ในทางกลับกัน องค์กรที่ยังมีปัญหาแบบ “ข้อมูลลูกค้าอยู่ใน Excel ของพนักงานคนหนึ่ง”, “ข้อมูลเก่าอยู่ในระบบ Legacy”, “ไม่รู้ว่า Marketing ส่งข้อมูลให้ Vendor รายไหน” หรือ “ไม่รู้ว่าใครเป็นเจ้าของฐานข้อมูล” จะเริ่มเห็นปัญหาทันทีเมื่อมีคำขอจริง
และยังมีอีกเรื่องที่อันตรายกว่า “ตอบช้า”
คือ ตอบผิด
หากรวบรวมข้อมูลได้แล้วแต่มีข้อมูลของลูกค้าคนอื่นติดไปด้วย เช่น เบอร์โทรศัพท์ของบุคคลที่สาม ข้อความสนทนากับพนักงาน หรือภาพจาก CCTV องค์กรก็มีโจทย์ด้านความเป็นส่วนตัวอีกชั้นหนึ่ง การเปิดเผยข้อมูลจึงไม่ใช่แค่ “Export CSV แล้วส่งให้ลูกค้า”
ประกาศยังเกี่ยวข้องกับการปกปิดหรือตัดข้อมูลของบุคคลอื่นในกรณีที่จำเป็น และกำหนดให้มีหลักฐานการดำเนินการเก็บไว้เพื่อรองรับการตรวจสอบภายหลัง
นี่จึงเป็นเรื่องของ Data Governance โดยตรง
องค์กรอาจมี Privacy Policy สวยมาก มี Cookie Banner ครบ และมี DPO แล้ว แต่ถ้าเมื่อมีลูกค้าขอข้อมูลแล้วต้องใช้เวลา 20 วันเพื่อค้นว่า “ข้อมูลลูกค้าอยู่ที่ไหน” ปัญหาที่แท้จริงไม่ได้อยู่ที่เอกสาร Privacy Policy
แต่อยู่ที่ Data Architecture ขององค์กร
“องค์กรที่ตอบ DSAR ได้เร็ว ไม่จำเป็นต้องมี AI ราคาแพงที่สุด แต่ต้องรู้ก่อนว่า ‘ข้อมูลของเราอยู่ตรงไหน’”
สำหรับ SME ข่าวนี้ไม่ได้หมายความว่าทุกบริษัทต้องรีบซื้อระบบ DSAR ราคาแพง สิ่งที่ควรทำก่อน คือ ออกแบบกระบวนการให้ชัดว่า ใครรับคำขอ ใครยืนยันตัวตน ใครค้นข้อมูล ใครตรวจสอบ ใครอนุมัติ และใครส่งมอบ
ส่วนองค์กรขนาดใหญ่ควรเริ่มคิดถึง DSAR ในฐานะ workflow ที่เชื่อมกับระบบข้อมูลจริง ไม่ใช่เพียงกล่องอีเมลของ DPO
สิ่งที่ควรทำต่อ: ก่อนวันที่ 14 กันยายน 2569
1. ทดลอง “DSAR จริง” 1 เคส
เลือกข้อมูลพนักงานหรือลูกค้าหนึ่งราย แล้วจำลองว่าเจ้าของข้อมูลขอข้อมูลทั้งหมด จับเวลาตั้งแต่รับคำขอจนถึงขั้นตอนส่งมอบ แล้วดูว่าติดตรงไหน
2. ทำ Data Map แบบง่ายที่สุด
ตอบให้ได้ว่า
- ข้อมูลลูกค้าอยู่ระบบไหน
- ใครเป็นเจ้าของระบบ
- ใครสามารถค้นข้อมูลได้
- ใช้ข้อมูลอะไรเป็นตัวค้น เช่น อีเมล เบอร์โทร หรือ Customer ID
- ข้อมูลจาก Vendor ภายนอกอยู่ที่ไหน
3. กำหนด DSAR Owner ให้ชัด
อย่าให้ทุกคนคิดว่า “เรื่องนี้ DPO จัดการเอง” กำหนดผู้รับผิดชอบตั้งแต่รับคำขอจนถึงส่งมอบ และกำหนด SLA ภายในองค์กรให้สั้นกว่า deadline ทางกฎหมาย
4. ซ้อมเรื่อง “ข้อมูลคนอื่นติดมาด้วย”
ทดสอบข้อมูลประเภทที่มีบุคคลหลายคนอยู่ในไฟล์เดียวกัน เช่น CCTV, Call Center, อีเมล หรือเอกสารร้องเรียน ต้องรู้ว่าจะปกปิดข้อมูลส่วนไหนก่อนส่ง
5. ตรวจหลักฐานและ Audit Trail
ต้องสามารถตอบย้อนหลังได้ว่า รับคำขอเมื่อไร → ตรวจตัวตนอย่างไร → ค้นข้อมูลจากไหน → ใครตรวจ → มีการปกปิดอะไร → ส่งให้ใคร → ส่งเมื่อไร เพราะการตอบคำขอให้เสร็จไม่ใช่จุดจบ สิ่งที่องค์กรต้องพิสูจน์ได้ภายหลังคือ กระบวนการทั้งหมดเกิดขึ้นอย่างไร
มุมมองผู้เชี่ยวชาญ
“ผมมองว่าประเด็นสำคัญไม่ใช่ 30 วันครับ แต่คือ วันนี้องค์กรรู้หรือยังว่าข้อมูลของลูกค้าหนึ่งคนกระจายอยู่ตรงไหนบ้าง เพราะถ้าตอบไม่ได้ ต่อให้มีเวลา 30 วันก็อาจไม่พอ”
แหล่งอ้างอิง
ต้นทางข่าว: iT24Hrs — ข่าวเกี่ยวกับประกาศหลักเกณฑ์การเข้าถึงและขอสำเนาข้อมูลส่วนบุคคล พ.ศ. 2569
เอกสารราชกิจจานุเบกษาที่เกี่ยวข้อง: ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์เกี่ยวกับการเข้าถึงและการขอรับสำเนาข้อมูลส่วนบุคคลฯ พ.ศ. 2569 ซึ่งเผยแพร่ในราชกิจจานุเบกษา เล่ม 143 ตอนพิเศษ 175 ง วันที่ 16 กรกฎาคม 2569
