เอกสาร PDPA มีครบแล้ว แปลว่าองค์กรปฏิบัติตาม PDPA แล้วจริงหรือ?
เมื่อผู้บริหารถามว่า “องค์กรทำ PDPA ครบแล้วหรือยัง” ทีมงานมักตอบว่า มี Privacy Notice มี RoPA มี DPA มีแบบฟอร์มความยินยอม และมีขั้นตอนรองรับสิทธิครบแล้ว
คำตอบนี้ฟังดูน่าเชื่อถือ แต่เอกสารเหล่านั้นยังตอบไม่ได้ว่า สิ่งที่กำหนดไว้ถูกนำไปใช้จริงหรือไม่ ระบบรองรับหรือไม่ ผู้ปฏิบัติงานเข้าใจหน้าที่เพียงใด และมีหลักฐานอะไรยืนยันว่า Control ทำงานได้ตามที่ออกแบบ
มีเอกสารครบ ยังไม่เท่ากับระบบทำงานจริง
องค์กรจำนวนมากประเมินความพร้อมด้วย Checklist และการยืนยันสถานะจากผู้รับผิดชอบ วิธีนี้ช่วยให้เห็นว่าเอกสารหรือกระบวนการใด “มี” หรือ “ยังไม่มี” แต่ยังเป็นเพียง Self-declaration ไม่ใช่หลักฐานว่าระบบทำงานได้จริง
ตัวอย่างเช่น Privacy Notice อาจระบุวัตถุประสงค์ไว้อย่างครบถ้วน แต่ฝ่ายการตลาดอาจนำข้อมูลไปใช้ในกิจกรรมใหม่โดยไม่ได้แจ้งเจ้าของข้อมูล RoPA อาจจัดทำไว้แล้ว แต่ไม่อัปเดตเมื่อเปลี่ยนระบบคลาวด์หรือนำ AI มาใช้ นโยบายลบข้อมูลอาจกำหนดเวลาไว้ชัดเจน แต่ข้อมูลจริงยังคงค้างอยู่ในระบบสำรอง หรือสิทธิการเข้าถึงอาจไม่ได้ถูกยกเลิกหลังพนักงานออกจากงาน
ปัญหาจึงไม่ใช่เพียงการขาดเอกสาร แต่คือระยะห่างระหว่างสิ่งที่องค์กรเขียน สิ่งที่พนักงานเข้าใจ สิ่งที่ระบบรองรับ และสิ่งที่เกิดขึ้นจริง
Design – Implementation – Effectiveness
การประเมินความพร้อมด้าน PDPA ไม่ควรหยุดที่คำถามว่า “มีหรือไม่มี” แต่ควรตรวจอย่างน้อยสามชั้น
- Design ออกแบบไว้เหมาะสมหรือไม่
องค์กรต้องมีนโยบาย ขั้นตอน บทบาท และมาตรการที่สอดคล้องกับลักษณะการใช้ข้อมูลและระดับความเสี่ยง เอกสารเป็นหลักฐานส่วนหนึ่งสำหรับประเมินขั้น Design แต่ยังต้องตรวจความครบถ้วนและความเหมาะสมของสิ่งที่ออกแบบไว้
- Implementation นำไปปฏิบัติจริงหรือไม่
ต้องตรวจว่ามีผู้รับผิดชอบ ทรัพยากร ระบบสนับสนุน และการสื่อสารที่เพียงพอหรือไม่ ที่สำคัญคือต้องมี Evidence แสดงว่าหน่วยงานต่าง ๆ ดำเนินการตามที่กำหนด
- Effectiveness ควบคุมความเสี่ยงได้จริงหรือไม่
แม้กระบวนการจะถูกนำไปใช้แล้ว ยังต้องทดสอบว่ามาตรการนั้นช่วยป้องกันหรือค้นพบปัญหาได้หรือไม่ เมื่อพบข้อบกพร่อง องค์กรสามารถแก้ไขและป้องกันไม่ให้เกิดซ้ำได้เพียงใด
ผู้ตรวจที่ใช้กรอบนี้จะไม่ถามเพียงว่า “มีการทบทวนสิทธิการเข้าถึงหรือไม่” แต่จะขอดูหลักฐานการทบทวนครั้งล่าสุด ตรวจขอบเขตระบบ ผู้อนุมัติ ข้อผิดพลาดที่พบ และการแก้ไขที่เกิดขึ้นจริง
นี่คือความแตกต่างระหว่างการรู้ว่าองค์กรควรทำอะไร กับการพิสูจน์ว่าสิ่งนั้นทำงานจริง
มีคู่มือรองรับสิทธิ แต่ตอบคำขอไม่ทัน
ลองพิจารณาสถานการณ์สมมติของบริษัทผู้ให้บริการแห่งหนึ่ง บริษัทมีคู่มือรองรับสิทธิของเจ้าของข้อมูลที่เขียนไว้อย่างครบถ้วน และกำหนดเส้นทางการรับคำขอ การตรวจสอบตัวตน การค้นหาข้อมูล และการตอบกลับไว้ชัดเจน
วันหนึ่ง ลูกค้าขอให้ลบข้อมูลส่วนบุคคลทั้งหมดผ่าน Call Center แต่พนักงานไม่แน่ใจว่าต้องส่งเรื่องไปให้ใคร กว่าเรื่องจะถึง DPO ก็ผ่านไปหลายวัน เมื่อประสานฝ่าย IT กลับพบว่าข้อมูลกระจายอยู่ใน CRM ระบบบัญชี และ Backup ขณะที่ฝ่ายกฎหมายยังไม่ได้ร่วมพิจารณาว่าข้อมูลบางส่วนต้องเก็บต่อด้วยเหตุผลทางกฎหมายหรือไม่
ผลคือ บริษัทตอบคำขอไม่ทันตามกรอบเวลาที่กำหนด ทั้งที่มีคู่มือครบ
กรณีนี้แสดงให้เห็นว่าองค์กรผ่านชั้น Design แต่ยังมีช่องว่างใน Implementation และ Effectiveness เพราะกระบวนการยังไม่ถูกทดสอบ ผู้เกี่ยวข้องไม่เข้าใจบทบาท และระบบไม่รองรับการดำเนินงานแบบครบวงจร
สิ่งที่องค์กรควรทำตั้งแต่วันนี้
องค์กรไม่จำเป็นต้องเริ่มด้วยการตรวจทุกเรื่องพร้อมกัน แต่ควรเปลี่ยนจากการตรวจนับเอกสารไปสู่การประเมินจากหลักฐาน โดยเริ่มจากสี่เรื่องสำคัญ
- เลือกกระบวนการเสี่ยงสูง เช่น ข้อมูลอ่อนไหว ข้อมูลลูกค้าจำนวนมาก หรือการใช้ผู้ให้บริการภายนอก
- เชื่อม Requirement กับ Control และ Evidence ที่ควรมี
- ทดสอบกระบวนการจริงผ่าน Sample, Interview และ System Evidence
- จัดลำดับช่องว่างตามความเสี่ยง กำหนดเจ้าของเรื่อง และติดตาม Corrective Action
ผู้บริหารไม่จำเป็นต้องอ่านแบบฟอร์มทุกฉบับ แต่ควรถามให้ได้ว่า สิ่งที่ประกาศไว้ตรงกับการปฏิบัติจริงหรือไม่ มีหลักฐานเพียงพอหรือไม่ ช่องว่างใดมีผลต่อธุรกิจ ใครเป็นเจ้าของความเสี่ยง และมีการติดตามการแก้ไขอย่างไร
ช่องว่างที่แท้จริงคือการขาดคนที่ “ตรวจองค์กรเป็น”
หลายองค์กรมี DPO ฝ่ายกฎหมาย หรือ Compliance ที่เข้าใจข้อกำหนดของ PDPA และอาจมี Internal Audit ที่รู้วิธีตรวจสอบ แต่ยังขาดบุคลากรที่เชื่อมสองด้านเข้าด้วยกันได้
ทักษะที่ขาดจึงไม่ใช่การมี Checklist เพิ่มอีกชุด แต่คือความสามารถในการเชื่อม Requirement, Control และ Evidence เพื่อพิสูจน์ช่องว่างระหว่างสิ่งที่เขียนไว้กับสิ่งที่เกิดขึ้นจริง
หลักสูตร Data Protection Auditor Certification หรือ DPAC ออกแบบให้สอดคล้องกับกรอบการตรวจประเมินสำหรับ PDPA Certification ตามหลักเกณฑ์ของ สคส. และพัฒนาทักษะดังกล่าวผ่านการเรียนรู้ด้าน PDPA, Governance, Risk, Internal Control และ Audit Methodology ผู้เรียนสามารถเริ่มจากการเลือกหนึ่งกระบวนการเสี่ยงสูง จัดทำ Evidence Request List และทดสอบ Control จากตัวอย่างจริงได้
ผู้เรียนจึงไม่ได้กลับไปพร้อมเพียงชุดเอกสาร แต่ควรสามารถประเมินได้ว่า Control ถูกออกแบบเหมาะสมหรือไม่ ถูกนำไปใช้จริงหรือไม่ และทำงานได้อย่างมีประสิทธิผลเพียงใด
DPAC เป็นหลักสูตรพัฒนาความสามารถของบุคคล ไม่ใช่การรับรองระบบขององค์กรโดย สคส. และการผ่านหลักสูตรไม่ได้ทำให้ผู้เรียนเป็นผู้ตรวจของ สคส. โดยอัตโนมัติ
สรุปสาระสำคัญ
ความพร้อมด้าน PDPA ไม่ได้วัดจากจำนวนเอกสารที่องค์กรมี แต่วัดจากความสามารถที่จะพิสูจน์ว่า สิ่งที่กำหนดไว้นั้นถูกนำไปใช้และควบคุมความเสี่ยงได้จริง
ยังสรุปไม่ได้ เอกสารเหล่านี้แสดงว่าองค์กรได้ออกแบบสิ่งที่ควรทำ แต่ยังต้องตรวจว่าถูกนำไปใช้จริง มีหลักฐานสนับสนุน และควบคุมความเสี่ยงได้หรือไม่
มีประโยชน์สำหรับสำรวจสถานะเบื้องต้น แต่ไม่ควรใช้แทนการทดสอบจาก Evidence โดยเฉพาะในกระบวนการที่มีความเสี่ยงสูง
ควรเริ่มจากกระบวนการที่ใช้ข้อมูลอ่อนไหว ข้อมูลจำนวนมาก การตัดสินใจอัตโนมัติ การใช้ผู้ให้บริการภายนอก หรือกระบวนการที่หากล้มเหลวแล้วกระทบเจ้าของข้อมูลและธุรกิจสูง
บทสรุป
องค์กรไม่ควรถามเพียงว่า “เอกสารครบหรือยัง” แต่ควรถามต่อว่า “สิ่งที่เขียนไว้เกิดขึ้นจริงหรือไม่ และมีหลักฐานอะไรพิสูจน์คำตอบนั้น”
สำหรับองค์กรที่ต้องการเปลี่ยนจากการตรวจนับเอกสารไปสู่การประเมินตามกรอบ Design – Implementation – Effectiveness หลักสูตร DPAC ช่วยให้คณะทำงาน PDPA เริ่มจากกระบวนการเสี่ยงสูง ขอหลักฐานที่เหมาะสม และระบุช่องว่างที่ต้องแก้จากสภาพการทำงานจริง
อยากตรวจประเมิน PDPA แต่ไม่รู้จะเริ่มต้นยังไง
หลักสูตร “ผู้ตรวจประเมินการคุ้มครองข้อมูลส่วนบุคคล” Data Protection Auditor Certification (DPAC) รุ่นที่ 5
รายละเอียดเพิ่มเติมคลิกเลย!
เผยแพร่: 10 สิงหาคม 2569
อัปเดตล่าสุด: 10 สิงหาคม 2569
ช่องทางติดต่อ:
Facebook: PDPA Thailand
Line OA: @pdpathailand
Email: [email protected]
Website: www.pdpathailand.com
