วิธี Audit PDPA สำหรับ HR และ Recruitment ของธุรกิจ SaaS สตาร์ทอัพ และบริษัทเทคโนโลยี พร้อม Evidence ที่ควรเก็บ

การ Audit PDPA ฝั่ง HR และ Recruitment ของบริษัท SaaS ควรทำเป็นรอบ ไม่ใช่ทำครั้งเดียวแล้วจบ โดยเน้นตรวจ 4 จุด คือ ความยินยอมสำหรับข้อมูลอ่อนไหวในใบสมัคร ระยะเวลาการเก็บ CV ของผู้สมัครที่ไม่ผ่านและไฟล์พนักงานที่ลาออก สิทธิ์การเข้าถึงข้อมูล HR ภายในองค์กร และหลักฐานที่พิสูจน์ได้ว่าแต่ละขั้นตอนทำจริง ทีม Product, Engineering, Growth และ Privacy ควรร่วมกันตรวจอย่างน้อยทุก 6 เดือน และปรับปรุงตามช่องโหว่ที่พบ

บ่ายวันศุกร์ HR Manager ของบริษัท SaaS แห่งหนึ่งเปิดโฟลเดอร์ Google Drive ที่ชื่อ "CV ผู้สมัคร 2024-2026" เจอไฟล์เกือบสี่พันไฟล์ บางไฟล์มีข้อมูลศาสนา ผลตรวจสุขภาพ และประวัติอาชญากรรมที่ผู้สมัครกรอกมาเองในแบบฟอร์มสมัครงานเก่า ไม่มีใครจำได้ว่าใครมีสิทธิ์เปิดโฟลเดอร์นี้บ้าง และไม่มีนโยบายลบไฟล์ที่ชัดเจน คำถามที่ตามมาคือ ถ้าพรุ่งนี้มีผู้สมัครคนหนึ่งขอใช้สิทธิ์ให้ลบข้อมูลของตัวเอง บริษัทจะตอบได้ภายในกี่วัน และมีหลักฐานอะไรมายืนยันว่าทำตามที่พูด สถานการณ์แบบนี้คือจุดเริ่มต้นของการ Audit PDPA ฝั่ง HR และ Recruitment อย่างจริงจัง

ทำไม HR และ Recruitment ต้อง Audit แยกจากข้อมูลลูกค้า

ข้อมูลพนักงานและผู้สมัครงานต่างจากข้อมูลลูกค้าตรงที่มีสัดส่วนข้อมูลอ่อนไหวสูงกว่ามาก ใบสมัครงานจำนวนมากมีช่องกรอกศาสนา สถานะสมรส ข้อมูลสุขภาพสำหรับตำแหน่งที่ต้องยกของหนักหรือทำงานกะดึก และในบางแบบฟอร์มยังมีคำถามเกี่ยวกับประวัติอาชญากรรมสำหรับตำแหน่งที่เกี่ยวข้องกับการเงิน ข้อมูลเหล่านี้เข้าข่ายข้อมูลอ่อนไหวตาม PDPA ซึ่งต้องขอความยินยอมโดยชัดแจ้ง แยกจากการยินยอมทั่วไป และมีเกณฑ์ที่เข้มกว่าการอ้างฐานทางกฎหมายทั่วไปที่ใช้กับข้อมูลลูกค้า การ Audit จึงต้องมองเห็นทั้งวงจรชีวิตของข้อมูล ตั้งแต่ผู้สมัครกดส่งใบสมัคร ไปจนถึงวันที่พนักงานคนหนึ่งลาออกและไฟล์ของเขาควรถูกจัดการอย่างไรต่อ อีกประเด็นที่มักถูกมองข้ามคือข้อมูลที่เก็บระหว่างขั้นตอนสัมภาษณ์ เช่น บันทึกการประเมินจากผู้สัมภาษณ์หลายคน หรือผลทดสอบทักษะที่ผู้สมัครทำผ่านระบบออนไลน์ ข้อมูลเหล่านี้แม้ไม่ใช่ข้อมูลอ่อนไหวโดยตรง แต่ก็ยังเป็นข้อมูลส่วนบุคคลที่ต้องมีกำหนดเวลาการเก็บและสิทธิ์การเข้าถึงที่ชัดเจนเช่นกัน

จุดที่ 1: ตรวจความยินยอมสำหรับข้อมูลอ่อนไหวในใบสมัคร

เริ่มจากดึงแบบฟอร์มสมัครงานทุกช่องทางที่บริษัทใช้ ไม่ว่าจะเป็นฟอร์มบนเว็บไซต์ ระบบ ATS ที่จ้างภายนอก หรือแม้แต่การรับ CV ทางอีเมลตรงจากผู้สมัคร แล้วไล่ดูว่าช่องไหนเก็บข้อมูลที่เข้าข่ายอ่อนไหวบ้าง เช่น รูปถ่ายที่เผยเชื้อชาติ ศาสนา ข้อมูลสุขภาพ หรือประวัติอาชญากรรม จากนั้นตรวจว่าฟอร์มมีกลไกขอความยินยอมแยกต่างหากสำหรับข้อมูลเหล่านี้หรือไม่ ไม่ใช่แค่ปุ่ม "ยอมรับเงื่อนไข" รวมทุกอย่างไว้ในข้อเดียว หลักฐานที่ควรเก็บคือ ภาพหน้าจอของฟอร์ม ณ ช่วงเวลาที่ผู้สมัครกรอก บันทึกเวลาที่กดยินยอม และเวอร์ชันของนโยบายความเป็นส่วนตัวที่ใช้ในขณะนั้น เพราะฟอร์มมักถูกแก้ไขบ่อยตามการเติบโตของทีม Product ทีมที่มีคนดูแลเรื่องนี้เพียงคนเดียวควรทำรายการช่องกรอกทั้งหมดเป็นตารางง่ายๆ ระบุว่าช่องไหนเข้าข่ายข้อมูลอ่อนไหว มีกลไกยินยอมแยกหรือยัง และใครเป็นผู้รับผิดชอบแก้ไขถ้ายังไม่มี วิธีนี้ช่วยให้เห็นภาพรวมได้เร็วกว่าการไล่เปิดฟอร์มทีละช่องทางทุกครั้งที่ต้อง Audit

จุดที่ 2: ตรวจระยะเวลาการเก็บ CV ผู้สมัครที่ไม่ผ่าน

ปัญหาที่พบบ่อยในบริษัท SaaS คือการเก็บ CV ผู้สมัครที่ไม่ผ่านไว้ "เผื่อมีตำแหน่งเปิดในอนาคต" โดยไม่มีกำหนดเวลาหรือฐานทางกฎหมายรองรับ การ Audit ต้องตรวจสามเรื่องคือ หนึ่ง มีนโยบายลายลักษณ์อักษรระบุระยะเวลาการเก็บ CV ของผู้สมัครที่ไม่ผ่านหรือไม่ สอง ระบบ ATS มีการลบหรือ Anonymize ข้อมูลอัตโนมัติเมื่อครบกำหนดหรือไม่ สาม ถ้าต้องการเก็บ CV ไว้นานกว่าปกติเพื่อพิจารณาตำแหน่งอื่นในอนาคต มีการขอความยินยอมเพิ่มเติมจากผู้สมัครหรือไม่ หลักฐานที่ต้องมีคือรายงานจากระบบ ATS ที่แสดงจำนวน CV ที่ถูกลบตามรอบ และ Log การลบที่ระบุวันที่ชัดเจน บริษัท SaaS บางแห่งพบว่าเมื่อไล่ตรวจจริง มี CV เก่ากว่าสามปีค้างอยู่ในระบบหลายร้อยไฟล์ โดยไม่มีใครเคยตั้งค่าลบมาก่อน กรณีแบบนี้ควรวางแผนลบเป็นรอบทีละชุดแทนการลบทีเดียวทั้งหมด เพื่อลดความเสี่ยงที่จะลบข้อมูลที่ยังมีเหตุจำเป็นต้องเก็บ เช่น ผู้สมัครที่อยู่ระหว่างกระบวนการร้องเรียนหรือข้อพิพาท

จุดที่ 3: ตรวจไฟล์ HR ของพนักงานปัจจุบันและพนักงานที่ลาออกแล้ว

เมื่อพนักงานคนหนึ่งลาออก ไฟล์ประเมินผลงาน สลิปเงินเดือน และข้อมูลสวัสดิการของเขาไม่ควรถูกเก็บไว้ตลอดไปโดยไม่มีเหตุผล การ Audit ควรตรวจว่าบริษัทมีตารางกำหนดระยะเวลาการเก็บไฟล์ HR แยกตามประเภท เช่น ข้อมูลสัญญาจ้างที่อาจต้องเก็บตามกฎหมายแรงงานหรือกฎหมายภาษี กับข้อมูลประเมินผลงานที่อาจไม่จำเป็นต้องเก็บนานเท่ากัน และตรวจว่าเมื่อครบกำหนดมีขั้นตอนลบหรือทำให้ข้อมูลไม่สามารถระบุตัวตนได้จริงหรือไม่ ไม่ใช่แค่ย้ายไปโฟลเดอร์ที่ชื่อ "Archive" แล้วปล่อยไว้ไม่มีกำหนด ข้อมูลบางประเภท เช่น สัญญาจ้างงานหรือเอกสารที่เกี่ยวข้องกับภาษีและประกันสังคม อาจมีข้อกำหนดให้เก็บตามระยะเวลาที่กฎหมายอื่นกำหนดไว้ ทีม HR จึงควรปรึกษากับฝ่ายบัญชีหรือที่ปรึกษากฎหมายก่อนตั้งกำหนดเวลาลบ เพื่อไม่ให้ลบข้อมูลที่ยังจำเป็นต้องเก็บตามกฎหมายอื่นออกไปก่อนเวลาอันควร

จุดที่ 4: ตรวจสิทธิ์การเข้าถึงข้อมูล HR แบบ Need-to-know

ในบริษัท SaaS ขนาดเล็กที่ทีมยังไม่ใหญ่ มักเกิดสถานการณ์ที่ผู้จัดการทีม Engineering หรือ Growth มีสิทธิ์เข้าถึงระบบ HR เดียวกับที่ HR ใช้ทั้งหมด ทั้งที่จริงแล้วควรเห็นเฉพาะข้อมูลของทีมตัวเอง การ Audit ต้องดึงรายชื่อผู้ใช้งานทั้งหมดในระบบ HR และ ATS แล้วเทียบกับตำแหน่งงานจริง ตรวจว่าใครเห็นข้อมูลอ่อนไหวอย่างศาสนาหรือสุขภาพได้บ้าง และพิจารณาว่าจำเป็นจริงหรือไม่ หลักฐานที่ควรเก็บคือรายงานสิทธิ์การเข้าถึงที่ Export จากระบบ พร้อมวันที่ตรวจสอบและชื่อผู้อนุมัติสิทธิ์แต่ละคน

ตารางสรุปจุดตรวจและหลักฐานที่ควรเก็บ

วางรอบ Audit ให้เหมาะกับจังหวะการเติบโตของทีม

บริษัท SaaS ที่กำลังขยายทีมเร็วมักมีการเปลี่ยนเครื่องมือ ATS หรือปรับฟอร์มสมัครงานบ่อย การ Audit ทุก 6 เดือนจึงเหมาะกับจังหวะนี้มากกว่าการตรวจปีละครั้ง โดยควรผูกรอบ Audit เข้ากับเหตุการณ์สำคัญ เช่น ก่อนเปิดรับสมัครตำแหน่งใหม่จำนวนมาก หรือหลังเปลี่ยนระบบ ATS ทีมที่ควรเข้าร่วมไม่ใช่แค่ HR แต่รวมถึงตัวแทนจาก Product และ Engineering ที่ดูแลระบบเก็บข้อมูล และ Privacy Team ที่ให้คำแนะนำด้านกฎหมาย แต่ละรอบควรจบด้วยรายการช่องโหว่ที่พบ พร้อมผู้รับผิดชอบและกำหนดเวลาแก้ไข ไม่ใช่แค่รายงานแล้วปิดจบ การบันทึกผลการ Audit แต่ละรอบไว้เป็นเอกสารต่อเนื่องยังช่วยให้เห็นแนวโน้มได้ด้วยว่าช่องโหว่แบบเดิมเกิดซ้ำหรือไม่ ถ้าปัญหาเดียวกันถูกพบซ้ำทุกรอบ นั่นเป็นสัญญาณว่าต้องแก้ที่ต้นเหตุของกระบวนการ ไม่ใช่แค่แก้เฉพาะหน้าทีละครั้ง

ตัวอย่างสถานการณ์ที่มักพบเมื่อ Audit จริง

ในการ Audit รอบแรกของบริษัท SaaS หลายแห่ง มักพบสามรูปแบบซ้ำๆ กัน รูปแบบแรกคือฟอร์มสมัครงานที่คัดลอกมาจากเทมเพลตออนไลน์ซึ่งมีช่องข้อมูลส่วนตัวมากเกินความจำเป็น เช่น สถานะสมรสหรือศาสนา ทั้งที่ตำแหน่งที่เปิดรับไม่เกี่ยวข้องเลย รูปแบบที่สองคือระบบ ATS ที่ตั้งค่ามาจากผู้ให้บริการโดยไม่มีใครปรับแก้ระยะเวลาการเก็บข้อมูลตามนโยบายภายในของบริษัทเอง ทำให้ค่าเริ่มต้นของระบบกลายเป็นนโยบายจริงโดยไม่มีใครตั้งใจ และรูปแบบที่สามคือรายชื่อผู้มีสิทธิ์เข้าถึงระบบ HR ที่ไม่เคยถูกปรับปรุงตั้งแต่วันที่ติดตั้งระบบ ทำให้พนักงานที่ย้ายแผนกหรือลาออกไปแล้วยังมีสิทธิ์เข้าถึงข้อมูลอยู่ การรู้จักรูปแบบเหล่านี้ล่วงหน้าช่วยให้ทีมที่ Audit ครั้งแรกรู้ว่าควรเริ่มมองหาอะไรก่อน แทนที่จะไล่ตรวจทุกอย่างแบบไม่มีลำดับความสำคัญ

ข้อผิดพลาดที่พบบ่อยในการ Audit ฝั่ง HR และ Recruitment

• ใช้ฟอร์มยินยอมเดียวกันสำหรับข้อมูลทั่วไปและข้อมูลอ่อนไหว โดยไม่แยกช่องความยินยอมสำหรับศาสนา สุขภาพ หรือประวัติอาชญากรรม
• ไม่มีกำหนดเวลาลบ CV ของผู้สมัครที่ไม่ผ่าน ปล่อยให้สะสมในระบบเป็นปี
• ให้สิทธิ์เข้าถึงระบบ HR แบบเดียวกันทั้งบริษัท โดยไม่แยกตามความจำเป็นของแต่ละตำแหน่ง
• ไม่มีหลักฐานเป็นลายลักษณ์อักษรว่าผู้สมัครยินยอมให้เก็บข้อมูลอ่อนไหว มีเพียงความเข้าใจปากเปล่า
• ลืมตรวจสอบผู้ให้บริการภายนอก เช่น ระบบ ATS หรือระบบตรวจประวัติ ว่ามีสัญญาประมวลผลข้อมูลที่ชัดเจนหรือไม่

บทสรุป: Audit คือกิจวัตร ไม่ใช่งานครั้งเดียว

การ Audit PDPA ฝั่ง HR และ Recruitment ที่ได้ผลจริงต้องทำซ้ำเป็นรอบ ไม่ใช่โครงการที่ทำครั้งเดียวแล้วเก็บรายงานไว้เฉยๆ ทีม SaaS ที่มีทรัพยากรจำกัดสามารถเริ่มจากสี่จุดที่กล่าวมา คือ ความยินยอมข้อมูลอ่อนไหว ระยะเวลาการเก็บ CV สิทธิ์การเข้าถึงข้อมูล และหลักฐานที่พิสูจน์ได้ แล้วค่อยขยายขอบเขตตามความซับซ้อนที่เพิ่มขึ้นของทีม การมีหลักฐานที่ตรวจสอบย้อนกลับได้คือสิ่งที่ทำให้ Audit มีความหมาย มากกว่าการมีนโยบายสวยงามที่ไม่มีใครทำตามจริง ดูภาพรวมเพิ่มเติมได้ที่ ศูนย์ความรู้ด้านธุรกิจและอุตสาหกรรม และเทียบกับขั้นตอนลงมือทำจริงใน วิธีทำ PDPA สำหรับ HR และ Recruitment ของ SaaS

แหล่งข้อมูลอ้างอิง

ตรวจสอบเกณฑ์ข้อมูลอ่อนไหวและระยะเวลาการเก็บรักษาข้อมูลกับสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) โดยตรง เนื่องจากแนวปฏิบัติอาจมีการปรับปรุงเป็นระยะ และควรตรวจสอบ เช็กลิสต์ก่อนเปิดใช้งานระบบ HR ใหม่ ประกอบก่อนนำไปปรับใช้จริง