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

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

กำหนดขอบเขตก่อนเริ่ม Audit

ก่อนเริ่มตรวจ ทีมควรตกลงกันก่อนว่า Audit รอบนี้ครอบคลุมเว็บไซต์สมัครงานหน้าใดบ้าง เช่น หน้าประกาศรับสมัครทั่วไป หน้าฟอร์มสมัครตำแหน่งเฉพาะ หรือหน้า Career ที่ทำผ่านแพลตฟอร์มภายนอกอย่าง LinkedIn หรือ JobsDB ที่ฝังลิงก์กลับมาที่เว็บไซต์บริษัท ขอบเขตที่ชัดเจนจะทำให้ Evidence ที่เก็บมาไม่กระจัดกระจายจนตรวจซ้ำในรอบหน้าไม่ได้

ขั้นตอนที่ 1 สำรวจ Data Flow ของกระบวนการสมัครงาน

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

ขั้นตอนที่ 2 ตรวจฟอร์มสมัครงานและข้อความแจ้งการใช้ข้อมูล

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

ตรวจฟิลด์ที่บังคับกรอกเทียบกับที่ใช้จริงในการคัดกรอง

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

ขั้นตอนที่ 3 ตรวจสิทธิ์การเข้าถึงและผู้ให้บริการภายนอก

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

ขั้นตอนที่ 4 ตรวจ Retention และการลบข้อมูล

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

ข้อมูลอ่อนไหวที่ต้องตรวจเป็นพิเศษระหว่าง Audit

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

คำถามที่ควรถามเมื่อพบข้อมูลอ่อนไหวในกระบวนการสมัครงาน

ทีมควรถามว่าข้อมูลนี้จำเป็นต่อการตัดสินใจจริงหรือไม่ ใครเป็นผู้เห็นข้อมูลนี้ได้บ้าง ข้อมูลถูกเก็บแยกจากข้อมูลทั่วไปหรือไม่ และมีการแจ้งผู้สมัครล่วงหน้าก่อนเข้าสู่ขั้นตอนที่ต้องให้ข้อมูลลักษณะนี้หรือไม่ หากคำตอบไม่ชัดในข้อใดข้อหนึ่ง ควรยกระดับเป็นประเด็นที่ต้องส่งให้ฝ่ายกฎหมายหรือ DPO พิจารณาก่อนดำเนินการต่อ ไม่ใช่ปล่อยให้ทีมสรรหาตัดสินใจเองทั้งหมด

เตรียมรายงานผล Audit ให้ผู้บริหารอ่านต่อได้

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

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

ตาราง Evidence ที่ควรเก็บระหว่าง Audit

บทบาทของ trusty ระหว่างการ Audit

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

เมื่อพบข้อขัดแย้งระหว่างทีมระหว่างการ Audit

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

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

คำถามที่พบบ่อย

Audit PDPA ภายในต้องทำบ่อยแค่ไหน

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

Audit ภายในต่างจาก PDPA Readiness Scan อย่างไร

PDPA Readiness Scan ตรวจสิ่งที่มองเห็นได้จากหน้าเว็บสาธารณะเป็นหลัก ส่วน Audit ภายในต้องตรวจกระบวนการเบื้องหลังด้วย เช่น สิทธิ์การเข้าถึงระบบและข้อตกลงกับผู้ให้บริการ ซึ่งเครื่องมือสแกนอัตโนมัติมองไม่เห็น

ถ้า Audit เจอปัญหาต้องแก้ทั้งหมดก่อนเปิดรับสมัครต่อหรือไม่

ไม่จำเป็นต้องหยุดกระบวนการรับสมัครทั้งหมด แต่ควรจัดลำดับความสำคัญ โดยแก้จุดที่มีความเสี่ยงสูงก่อน เช่น บัญชีพนักงานที่ลาออกแล้วแต่ยังเข้าถึงข้อมูลได้ ก่อนไปแก้จุดที่เป็นรายละเอียดปลีกย่อย

ใครควรเป็นเจ้าของผลการ Audit

ควรมีเจ้าของชัดเจนอย่างน้อยหนึ่งคนในทีม HR ที่รับผิดชอบติดตามว่าแต่ละ Finding ถูกแก้ไปถึงไหน ไม่ใช่ปล่อยให้ผลการ Audit เป็นเอกสารที่ไม่มีใครติดตามต่อ เจ้าของงานควรนัดทบทวนความคืบหน้ากับทีมที่เกี่ยวข้องเป็นระยะ เช่น ทุกเดือนในช่วงสามเดือนแรกหลัง Audit เพื่อให้ Finding ที่มีความเสี่ยงสูงไม่ค้างอยู่ในสถานะรอแก้นานเกินไป

เช็กลิสต์ปฏิบัติ

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

ข้อผิดพลาดที่พบบ่อย

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

สรุป

การ Audit PDPA ของเว็บไซต์สมัครงานที่ใช้งานได้จริง ต้องมีทั้งขั้นตอนที่ทำซ้ำได้และ Evidence ที่เก็บไว้อ้างอิงในรอบถัดไป ไม่ใช่แค่ตอบว่าผ่านหรือไม่ผ่าน ทีมที่เริ่มจากการวาด Data Flow และทำตารางเก็บ Evidence อย่างสม่ำเสมอ จะเห็นจุดที่ต้องแก้ก่อนได้ชัดกว่าการรอให้มีปัญหาแล้วค่อยย้อนกลับมาตรวจ

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

• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)
• เช็กลิสต์ PDPA สำหรับเว็บไซต์สมัครงาน ก่อนเปิดใช้งาน
• อัปเดต PDPA สำหรับเว็บไซต์สมัครงาน ปี 2026