วิธี Audit Data Retention ของเว็บไซต์ธุรกิจทั่วไปและ SME พร้อม Evidence ที่ควรเก็บ

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

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

สัญญาณที่บอกว่าตารางระยะเก็บมีอยู่จริงหรือแค่เป็นเอกสารที่ทำไว้เฉยๆ

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

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

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

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

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

วิธีตรวจสอบว่าเคยลบข้อมูลตามกำหนดจริงหรือแค่มีตารางไว้เฉยๆ

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

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

วิธีตรวจสอบว่าการลบครอบคลุมทุกระบบ รวม Backup และ Vendor

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

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

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

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

ตัวอย่างผลลัพธ์ที่พบบ่อยเมื่อ Audit ครั้งแรก

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

วิธีจัดลำดับความสำคัญหลัง Audit เสร็จ

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

ใครควรเป็นผู้ทำ Audit Data Retention ในธุรกิจขนาดเล็ก

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

ความถี่ในการทำ Audit ซ้ำ

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

เครื่องมือที่ช่วยให้การ Audit ทำได้เร็วขึ้น

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

กรณีตัวอย่างช่องว่างที่พบบ่อยตามประเภทข้อมูล

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

ผลกระทบที่อาจเกิดขึ้นเมื่อไม่เคย Audit เลย

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

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

ควร Audit Data Retention บ่อยแค่ไหน

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

ถ้าตรวจแล้วพบว่าข้อมูลที่ควรลบยังอยู่ในระบบจำนวนมาก ควรทำอย่างไรก่อน

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

ต้องตรวจ Backup ทุกครั้งที่ Audit หรือไม่

ควรตรวจอย่างน้อยครั้งแรกที่ทำ Audit เพื่อให้รู้ว่านโยบายลบข้อมูลใน Backup เป็นอย่างไร และตรวจซ้ำทุกครั้งที่มีการเปลี่ยนผู้ให้บริการ Backup หรือเปลี่ยนวิธีสำรองข้อมูล

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

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

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

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

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

สรุป

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

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

• NIST Privacy Framework