ปี 2569 นับเป็นปีที่ 7 นับจากประกาศใช้ และกำลังก้าวเข้าสู่ปีที่ 4 ของการบังคับใช้เต็มรูปแบบของพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 หรือ PDPA หลายองค์กรมักเริ่มทำ PDPA ด้วยวิธีที่ “ถูกต้องในเชิงเอกสาร” เป็นอันดับแรก คือรีบจัดทำนโยบาย, แบบฟอร์ม หรือจัดทำประกาศให้ครบตามรายการตรวจสอบ
แต่เมื่อเวลาผ่านไปกลับพบปัญหา เช่น มีคำถามจากลูกค้าหรือพนักงานเข้ามาแล้วตอบไม่ตรงประเด็น พอมีเหตุหรือมีการตรวจสอบก็หา “หลักฐานการปฏิบัติ” ไม่เจอ หรือบางครั้งยิ่งทำยิ่งรู้สึกว่าการทำ PDPA กลายเป็นภาระของไม่กี่คน
แนวโน้มที่เกิดขึ้นจริงคือความท้าทายของ PDPA จะยิ่งชัดขึ้น เพราะการทำงานขององค์กรต้องพึ่งพาระบบดิจิทัลมากขึ้น ทั้ง Cloud, ระบบสมาชิก, CRM, เครื่องมือการตลาด, ผู้ให้บริการภายนอก และการทำงานแบบข้ามทีม-ข้ามสาขา ข้อมูลส่วนบุคคลจึงไหลผ่านหลายจุดมากกว่าเดิม และความเสี่ยงไม่ได้อยู่ที่ “ตัวบทกฎหมาย” อย่างเดียว แต่อยู่ที่ “ทักษะการทำงาน” ที่ทำให้ PDPA กลายเป็นระบบปฏิบัติการจริงในองค์กร
PDPA Thailand ชวนอัปเดตความรู้ สู่การสร้างทักษะ (Skills) การปฏิบัติตามกฎหมาย ในปี 2569
แน่นอนว่าผู้ดูแลด้าน PDPA ขององค์กร ต้องมีความเข้าใจตัวบทกฎหมายเป็นจุดเริ่มต้น “แต่ไม่ใช่แค่รู้แล้วจบ” เพราะในโลกขององค์กร คำถามสำคัญไม่ใช่ “มาตราไหนว่าอะไร” แต่คือ “เราต้องทำอะไรเพิ่ม” และ “ใครต้องทำ” ในหลายกรณี PDPA ถูกมองเป็นเรื่องของฝ่ายกฎหมายเพียงฝ่ายเดียว จึงกลายเป็นงานที่อยู่ในเอกสาร ไม่ได้ฝังอยู่ในกระบวนการทำงานจริง
ทักษะแรกที่คนทำ PDPA ต้องมี คือความสามารถในการแปลงข้อกำหนดให้เป็นงานปฏิบัติที่ทีมต่าง ๆ ทำตามได้ โดยไม่ต้องตีความเองทุกครั้ง เช่น ถ้าองค์กรมีการเก็บข้อมูลลูกค้าเพื่อทำการตลาด คนทำ PDPA ต้องตอบให้ชัดว่า “ต้องแจ้งอะไรกับเจ้าของข้อมูล”, “ใช้ฐานกฎหมายอะไร”, “ข้อมูลถูกส่งต่อให้ใครและเพราะอะไร”, “เก็บนานแค่ไหนและทำลายข้อมูลอย่างไร” เมื่อแปลงเป็นภาพงานที่จับต้องได้แล้ว จึงจะกำหนดเจ้าของข้อมูล (data owner) ได้
“หัวใจของทักษะนี้คือการทำให้ PDPA ไม่เป็นภาระของคนคนเดียว แต่กลายเป็นความรับผิดชอบร่วมของหลายทีม โดยมีแผนงานที่ทุกคนเข้าใจตรงกัน”
PDPA ในเชิงการปฏิบัติเริ่มจากคำถามง่าย ๆ แต่สำคัญมาก “ข้อมูลอยู่ที่ไหน และไหลไปไหน” ถ้าองค์กรตอบคำถามนี้ไม่ได้ จะจัดการความเสี่ยงได้ยาก และเมื่อมีเหตุหรือมีคำขอใช้สิทธิ (DSAR) ก็จะยิ่งแก้ปัญหาแบบวิ่งหาข้อมูลกันทั้งองค์กร
Data Mapping และ RoPA (Record of Processing Activities) ที่ดีจึงไม่ใช่แค่รายการข้อมูลในไฟล์ Excel แต่เป็นแผนที่ของการทำงานจริงที่ช่วยให้เห็นเส้นทางข้อมูล ตั้งแต่จุดที่องค์กรรับข้อมูลเข้ามา จุดที่นำไปใช้ จุดที่ส่งต่อให้คนอื่น (เช่น ผู้รับจ้าง หรือผู้ให้บริการระบบ) จนถึงจุดที่จัดเก็บและทำลายข้อมูล การทำ RoPA ให้ใช้งานได้จริงมักต้องเริ่มจากการ “เดินกระบวนการ” กับทีมหน้างาน เช่น ฝ่ายขาย, บริการลูกค้า, HR, IT แล้วค่อยสรุปเป็นภาพรวม ไม่ใช่เริ่มจากแบบฟอร์มสำเร็จรูปเพียงอย่างเดียว
เมื่อ RoPA ทำงานได้จริง คนทำ PDPA จะตอบคำถามสำคัญได้เร็วขึ้น เช่น “ข้อมูลนี้มีอยู่ในระบบไหนบ้าง”, “ใครเข้าถึงได้”, “ใช้เพื่ออะไร”, “ส่งต่อให้ใคร”, “ต้องเก็บนานแค่ไหน” และที่สำคัญคือช่วยให้การตัดสินใจเรื่องการปรับกระบวนการของแต่ละกิจกรรม และมีหลักฐานรองรับ
หนึ่งในความเข้าใจผิดที่พบบ่อยในองค์กรคือ “ทำ PDPA = ขอความยินยอม (Consent) ให้เยอะไว้ก่อน” แต่ในความเป็นจริง การประมวลผลข้อมูลส่วนบุคคลมีหลายฐานกฎหมาย และการเลือกฐานที่เหมาะสมต้องอิงจากวัตถุประสงค์และบริบทการทำงาน หากเลือกฐานผิดหรือสื่อสารไม่ชัด จะเกิดความเสี่ยงทั้งด้านข้อกฎหมายและความเชื่อมั่น
ทักษะสำคัญจึงอยู่ที่การ “ออกแบบการสื่อสารและหลักฐานให้พิสูจน์ได้” ไม่ใช่แค่เขียนข้อความให้ครบ เช่น Privacy Notice ต้องอ่านรู้เรื่องสำหรับคนทั่วไป แต่ยังต้องมีสาระที่ครบตามกรอบของ PDPA เช่นเดียวกับ Consent ต้องจัดการได้เป็นระบบ เช่น มีบันทึกว่าคนให้ความยินยอมเมื่อไร ผ่านช่องทางใด และมีวิธีจัดการเมื่อเจ้าของข้อมูลถอนความยินยอม
หากองค์กรที่ทำส่วนนี้ดีจะไม่สะดุดเวลาถูกถามว่า “ตอนนั้นแจ้งอะไรไว้” หรือ “เจ้าของข้อมูลยินยอมจริงไหม” เพราะสามารถเปิดหลักฐานที่ตรวจสอบย้อนกลับได้ทันที
PDPA ไม่ได้เป็นงานเอกสารล้วน ๆ เพราะอีกนัยหนึ่งคืองานบริหารความเสี่ยง โดยเฉพาะเมื่อองค์กรมีโครงการใหม่ ระบบใหม่ หรือการใช้เทคโนโลยีที่มีความเสี่ยงสูง เช่น การใช้ผู้ให้บริการภายนอก (Outsourced), การทำ Profiling, การใช้ AI ในการคัดกรอง-ประเมิน หรือการประมวลผลข้อมูลที่ละเอียดอ่อนในบางบริบท
ดังนั้นการประเมินผลกระทบด้านการคุ้มครองข้อมูลส่วนบุคคล หรือ DPIA (Data Protection Impact Assessment) จะเข้ามามีบทบาทเพื่อช่วยให้องค์กร “เห็นความเสี่ยงก่อนเกิดเหตุ” และวางมาตรการลดความเสี่ยงอย่างเป็นรูปธรรม
ทักษะที่คนทำ PDPA ต้องมีจึงไม่ใช่การกรอกแบบฟอร์มให้ครบ แต่คือการตั้งคำถามที่ถูกต้อง เช่น ข้อมูลนี้มีความจำเป็นหรือไม่ในการเก็บรวบรวม สามารถไม่เก็บหรือเก็บน้อยลงได้หรือไม่ร, ใครเข้าถึงข้อมูลนี้ได้บ้าง, มีการกำหนดสิทธิ (access control) หรือการเข้ารหัส (encryption) หรือไม่, และหากเกิดเหตุขึ้นใครตัดสินใจอะไรบนหลักฐานทางกฎหมายใด
เมื่อ DPIA ถูกทำแบบ “risk-based” จริง ๆ สิ่งนี้จะกลายเป็นเครื่องมือคุ้มครององค์กรทั้งด้านความเสี่ยงและด้านความเชื่อมั่น ไม่ใช่ภาระที่ถูกทำซ้ำทุกครั้งและไม่สามารถใช้งานได้จริง
