ข้อมูลบุคลากร เก็บรักษา และลบอย่างไร

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

ข้อมูลบุคลากรต้องเก็บรักษานานเท่าใด?

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

สิ่งที่ทำได้แทนการอ้างตัวเลขคือการสร้างกรอบตัดสินใจ ซึ่งมีสี่คำถามที่ต้องตอบให้ได้ก่อนกำหนดระยะเวลา

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

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

เพราะเหตุใดการลบข้อมูลจึงยากกว่าที่คิด?

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

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

ปัญหาข้อที่สามคือการลบที่ทำในทางเทคนิคอาจไม่ใช่การลบจริง ในหลายระบบการลบคือการทำเครื่องหมายว่าลบ ขณะที่ข้อมูลยังอยู่ในฐานข้อมูล การทำเครื่องหมายว่าลบอาจเพียงพอต่อการใช้งาน แต่ไม่เพียงพอต่อการรับรองว่าข้อมูลหายไปแล้ว

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

ข้อมูลประเภทต่าง ๆ ควรถูกจัดการต่างกันอย่างไร?

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

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

เอกสารของผู้สมัครที่ไม่ผ่านการคัดเลือกควรเก็บนานเท่าใด?

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

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

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

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

เพราะเหตุใดระบบทดสอบจึงไม่ควรมีข้อมูลบุคลากรจริง?

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

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

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

สำหรับนักพัฒนา: การนำนโยบายการเก็บรักษาไปใช้

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

ข้อที่สองคือกำหนดเจ้าของข้อมูลแต่ละประเภทให้ชัด เมื่อไม่มีเจ้าของ ไม่มีใครตัดสินใจลบ และข้อมูลจะค้างอยู่ตลอดไป

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

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

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

ขั้นตอนถัดไป

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

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

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