เช็กลิสต์ PDPA สำหรับ HR และ Recruitment สำหรับธุรกิจ SaaS สตาร์ทอัพ และบริษัทเทคโนโลยี: ต้องตรวจอะไรบ้างก่อนเปิดใช้งาน

ก่อนเปิดใช้งานระบบรับสมัครงานหรือฟอร์มสมัครงานใหม่ในบริษัท SaaS ควรตรวจครบ 5 กลุ่ม คือ ช่องเก็บข้อมูลอ่อนไหวในฟอร์ม กลไกขอความยินยอมแยกสำหรับข้อมูลอ่อนไหว กำหนดเวลาลบ CV ของผู้ไม่ผ่านการคัดเลือก สิทธิ์การเข้าถึงข้อมูลแบบ need-to-know และสัญญากับผู้ให้บริการ ATS ภายนอก การเช็กลิสต์นี้ใช้ก่อนเปิดตัวฟีเจอร์ใหม่หรือเปลี่ยนระบบ ไม่ใช่ทำครั้งเดียวแล้วจบ

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

กลุ่มที่ 1: ฟอร์มสมัครงานและช่องเก็บข้อมูลอ่อนไหว

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

กลุ่มที่ 2: กลไกขอความยินยอมแยกสำหรับข้อมูลอ่อนไหว

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

กลุ่มที่ 3: กำหนดเวลาลบ CV และไฟล์ที่ไม่ผ่านการคัดเลือก

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

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

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

กลุ่มที่ 5: สัญญากับผู้ให้บริการ ATS หรือระบบภายนอก

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

ข้อผิดพลาดที่พบบ่อยก่อนเปิดใช้งานระบบ HR ใหม่

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

ทีมที่มีทรัพยากรจำกัดควรถือว่าเช็กลิสต์นี้เป็นขั้นต่ำที่ต้องผ่านก่อน Go-live ไม่ใช่รายการที่เลือกทำเฉพาะข้อที่สะดวก

ใครควรเป็นผู้เซ็นอนุมัติก่อนเปิดใช้งานจริง

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

เช็กลิสต์นี้ใช้ซ้ำได้ทุกครั้งที่เปลี่ยนระบบ

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

บทสรุป: เช็กก่อนเปิดใช้งานดีกว่าตามแก้ทีหลัง

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

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

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