วิธีวางระบบ Data Retention สำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์แบบเป็นขั้นตอน

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

ขั้นที่ 1: ไล่สำรวจว่าเก็บข้อมูลอะไรไว้ที่ไหนบ้าง

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

• ฐานข้อมูล CMS ของเว็บไซต์ที่ดูแลอยู่ (WordPress, headless CMS ฯลฯ)
• แบ็กอัปเว็บไซต์ทั้งแบบอัตโนมัติและแบบที่ทีมสำรองเอง
• เครื่องมือฟอร์มติดต่อ/ลีด และ CRM ที่ใช้เก็บข้อมูลผู้สนใจ
• เครื่องมือวิเคราะห์เว็บไซต์และปลั๊กอินติดตามผู้ใช้
• โฟลเดอร์ไฟล์งานภายในทีมและกล่องอีเมลที่ใช้ติดต่อลูกค้า

ขั้นที่ 2: จัดกลุ่มข้อมูลตามลักษณะการใช้งาน ไม่ใช่ตามระบบ

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

ขั้นที่ 3: กำหนดระยะเวลาเก็บและจุดเริ่มนับ

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

ขั้นที่ 4: ออกแบบกลไกลบหรือ Anonymize ที่ทำซ้ำได้

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

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

ขั้นที่ 5: มอบหมายเจ้าของงานและบันทึกหลักฐาน

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

ขั้นที่ 6: ผูกเข้ากับสัญญาและขั้นตอนปิดโปรเจกต์

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

ตัวอย่างการนำไปปรับใช้กับเครื่องมือที่เอเจนซีนิยมใช้

ทีมที่ใช้ WordPress เป็นหลักสามารถเริ่มจากปลั๊กอินจัดการผู้ใช้ที่มีฟังก์ชันลบบัญชีเป็นชุด แล้วตั้งตารางงานให้รันตามรอบที่กำหนดแทนการลบทีละบัญชีด้วยมือ ส่วนทีมที่ใช้ headless CMS หรือระบบที่พัฒนาเอง ควรเขียนสคริปต์ฝั่งฐานข้อมูลที่ระบุเงื่อนไขวันหมดอายุชัดเจน เช่น ลบบัญชีที่ไม่มีการเข้าสู่ระบบเกิน 24 เดือนและไม่มีคำสั่งซื้อค้างอยู่ สำหรับเครื่องมือฟอร์มติดต่อและ CRM ยอดนิยม ส่วนใหญ่มีฟีเจอร์ตั้งค่าลบข้อมูลอัตโนมัติตามระยะเวลาอยู่แล้ว เพียงแต่ทีมต้องเข้าไปเปิดใช้งานเอง เพราะค่าเริ่มต้นของหลายระบบมักตั้งเป็นเก็บไว้ไม่จำกัดเวลา และสำหรับผู้ให้บริการโฮสติ้งที่ทำแบ็กอัปอัตโนมัติ ควรเข้าไปตรวจสอบว่าเก็บแบ็กอัปย้อนหลังกี่ชุดกี่วัน แล้วปรับให้สอดคล้องกับตารางที่ทีมกำหนดไว้เอง

ทดสอบระบบเป็นระยะเพื่อยืนยันว่าใช้งานได้จริง

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

ตัวอย่างการนำไปปรับใช้กับเครื่องมือที่เอเจนซีนิยมใช้

สำหรับทีมที่ใช้ WordPress เป็นหลัก สามารถเริ่มจากปลั๊กอินจัดการผู้ใช้ที่มีฟังก์ชันลบบัญชีเป็นชุด (bulk delete) แล้วตั้งตารางงานให้รันตามรอบที่กำหนดแทนการลบทีละบัญชี ส่วนทีมที่ใช้ headless CMS หรือระบบที่พัฒนาเอง ควรเขียนสคริปต์ฝั่งฐานข้อมูลที่ระบุเงื่อนไขวันหมดอายุชัดเจน เช่น ลบบัญชีที่ไม่มีการเข้าสู่ระบบเกิน 24 เดือนและไม่มีคำสั่งซื้อค้างอยู่ สำหรับเครื่องมือฟอร์มติดต่อและ CRM ยอดนิยม ส่วนใหญ่มีฟีเจอร์ตั้งค่าลบข้อมูลอัตโนมัติตามระยะเวลาอยู่แล้ว เพียงแต่ทีมต้องเข้าไปตั้งค่าเปิดใช้งานเอง เพราะค่าเริ่มต้นของหลายระบบมักตั้งเป็นเก็บไว้ไม่จำกัดเวลา

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

จะรู้ได้อย่างไรว่าระบบที่วางไว้ทำงานได้จริง

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

ข้อผิดพลาดที่พบบ่อยเมื่อวางระบบ Data Retention

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

สรุป

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

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

ขั้นตอนในบทความนี้อ้างอิงแนวคิดจาก NIST Privacy Framework ในส่วนของการบริหารวงจรชีวิตข้อมูล (data lifecycle) และแนวปฏิบัติทั่วไปของอุตสาหกรรมดิจิทัลเอเจนซีเรื่องการจัดการข้อมูลลูกค้าหลังปิดโปรเจกต์ ทีมควรตรวจสอบข้อกำหนดเฉพาะของกฎหมายที่เกี่ยวข้องกับประเทศที่ลูกค้าดำเนินธุรกิจอยู่เพิ่มเติมเสมอ ดูหัวข้ออื่นในกลุ่ม Data Governance ได้ที่ ศูนย์ความรู้ Data Governance