เปรียบเทียบแนวทางจัดการ Data Retention สำหรับธุรกิจ SaaS สตาร์ทอัพ และบริษัทเทคโนโลยี: ทำเอง ใช้ปลั๊กอิน หรือใช้แพลตฟอร์ม

ทีม Engineering ตั้งค่า log rotation ให้ลบ log เก่าเกิน 30 วันในระบบ observability มาตั้งแต่วันแรก แต่ไม่มีใครในทีม Privacy รู้ว่า event การใช้งานที่ส่งเข้า analytics tool ตัวที่สองถูกเก็บไว้ถาวรโดยไม่มีการลบเลย จนกระทั่งลูกค้าองค์กรถามระหว่างการทำ Security Review ว่าเก็บข้อมูลผู้ใช้นานแค่ไหน ทีมถึงรู้ว่าไม่มีคำตอบที่ตรงกันทั้งบริษัท

สถานการณ์นี้พบได้บ่อยใน SaaS เพราะข้อมูลกระจายอยู่ในหลายระบบที่แต่ละทีมดูแลแยกกัน ตั้งแต่ฐานข้อมูลหลัก ระบบ Analytics ระบบ Billing ไปจนถึง Subprocessor ภายนอกอย่าง Email หรือ Support Tool การจัดการ Data Retention จึงไม่ใช่แค่การตั้งนโยบายเอกสาร แต่ต้องเชื่อมกับการตั้งค่าจริงในระบบวิศวกรรม บทความนี้เทียบสามแนวทางที่ทีม SaaS เลือกใช้ คือทำเอง ใช้ปลั๊กอินหรือฟีเจอร์สำเร็จรูป และใช้แพลตฟอร์มจัดการความพร้อมด้านข้อมูล

Data Retention ในบริบท SaaS ครอบคลุมข้อมูลอะไรบ้าง

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

• บัญชีผู้ใช้ (user account) รวมอีเมลและข้อมูลโปรไฟล์
• Analytics event และ product usage log
• Server log และ error monitoring
• Backup ของฐานข้อมูล
• ข้อมูล Billing และประวัติการชำระเงิน
• Support ticket และประวัติแชท
• Subprocessor ที่รับข้อมูลต่อ เช่น Email service หรือ Customer support platform

นักพัฒนาต้องรับผิดชอบ Data Retention คนเดียวหรือไม่

ไม่ควร เพราะนักพัฒนาควบคุมได้เฉพาะสิ่งที่อยู่ในโค้ดและฐานข้อมูลที่ทีมดูแลโดยตรง ส่วนข้อมูลที่ส่งไปยัง Subprocessor ภายนอกหรือ Cookie บนเว็บไซต์การตลาดต้องมีทีม Privacy หรือ Product ร่วมรับผิดชอบด้วย งานนี้จึงควรเป็นความรับผิดชอบร่วมระหว่าง Engineering, Product และ Privacy ไม่ใช่ของทีมใดทีมหนึ่ง

ทำไมทีม Engineering กับทีม Privacy มักเก็บข้อมูลไม่ตรงกัน

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

ปัญหานี้ยิ่งชัดเมื่อบริษัทเติบโตเร็วและเพิ่มเครื่องมือใหม่บ่อย ทีม Growth อาจติดตั้ง Marketing Pixel หรือ Session Replay Tool โดยไม่แจ้งทีม Engineering หรือ Privacy ทำให้ข้อมูลผู้ใช้ถูกส่งไปยัง Vendor ที่ไม่มีใครทำ Data Inventory ไว้เลย

ต้องมีรายชื่อ Subprocessor ก่อนเริ่มทำ Data Retention หรือไม่

ควรมีตั้งแต่ต้น เพราะข้อมูลที่ส่งต่อไปยัง Subprocessor เช่น Email Service หรือ Support Tool มีนโยบายเก็บรักษาของตัวเอง หากไม่มีรายชื่อที่เป็นปัจจุบัน ทีมจะไม่รู้ว่าข้อมูลผู้ใช้ยังหลงเหลืออยู่ที่ไหนบ้าง และจะตอบคำถามจากลูกค้าองค์กรหรือทีม Security Review ไม่ได้เมื่อถูกถามตรงๆ ว่าใครถือข้อมูลอยู่บ้าง

สามแนวทางจัดการ Data Retention ของ SaaS

เมื่อรู้ขอบเขตข้อมูลแล้ว ทีม SaaS ส่วนใหญ่เลือกจากสามแนวทางนี้

ทำเอง คือการเขียนนโยบายและตั้งค่า TTL (time-to-live) ในฐานข้อมูลหรือ cron job ลบข้อมูลเก่าด้วยตัวเอง เหมาะกับทีมที่มีวิศวกรพร้อมอยู่แล้วและระบบยังไม่ซับซ้อนมาก จุดแข็งคือควบคุมได้ละเอียดถึงระดับ field ในฐานข้อมูล แต่ต้องมีวินัยในการบำรุงรักษาสคริปต์และปรับปรุงเมื่อ schema เปลี่ยน

ใช้ปลั๊กอินหรือฟีเจอร์สำเร็จรูป หมายถึงการพึ่งฟีเจอร์ Data Retention ที่มากับ Analytics Tool หรือ CRM ที่ใช้อยู่แล้ว เช่นตั้งค่าให้ลบ Event เก่าอัตโนมัติ วิธีนี้ติดตั้งเร็ว แต่ควบคุมได้เฉพาะข้อมูลในเครื่องมือนั้นเครื่องมือเดียว ไม่ครอบคลุมฐานข้อมูลหลักหรือ Subprocessor อื่น

ใช้แพลตฟอร์มจัดการความพร้อมด้านข้อมูล ช่วยให้ทีม Privacy เห็นภาพรวมของ Cookie, Tracking Script และสถานะ Consent บนเว็บไซต์การตลาดและหน้า Landing Page โดยไม่ต้องรอให้ Engineering รายงานด้วยมือ เหมาะกับบริษัทที่มีหลายผลิตภัณฑ์หรือหลายเว็บไซต์ย่อย

ตัวอย่างค่า Retention ที่ทีม SaaS มักตั้งตามประเภทข้อมูล

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

ตั้ง TTL เองมีข้อจำกัดตรงไหน

การตั้ง TTL ในฐานข้อมูลแก้ปัญหาได้เฉพาะข้อมูลที่อยู่ในฐานข้อมูลหลัก แต่ SaaS ส่วนใหญ่มีข้อมูลกระจายอยู่ใน Data Warehouse, Analytics Tool และ Log Aggregator ที่แยกกันคนละระบบ การตั้ง TTL เพียงจุดเดียวจึงอาจทำให้ทีมเข้าใจผิดว่าลบข้อมูลครบแล้ว ทั้งที่สำเนาข้อมูลยังอยู่ในระบบอื่นที่ไม่มีใครตรวจสอบ

ตั้ง TTL ในฐานข้อมูลอย่างเดียวเพียงพอหรือไม่

ไม่เพียงพอ เพราะ SaaS ส่วนใหญ่มีข้อมูลกระจายอยู่ใน Data Warehouse, Analytics Tool และ Log Aggregator ด้วย การตั้ง TTL เฉพาะฐานข้อมูลหลักอาจทำให้ทีมเข้าใจผิดว่าลบข้อมูลครบแล้วทั้งที่สำเนายังอยู่ในระบบอื่น ทีมจึงควรทำ Data Map ก่อนว่าข้อมูลประเภทเดียวกันไหลไปอยู่ในระบบใดบ้าง แล้วค่อยตั้งค่าลบให้ครบทุกจุด

อีกจุดเสี่ยงคือ Backup ฐานข้อมูล เมื่อ TTL ลบข้อมูลออกจากฐานข้อมูล production แล้ว ข้อมูลนั้นอาจยังอยู่ใน Backup เก่าตามรอบที่ทีม Infrastructure ตั้งไว้ ซึ่งบางครั้งนานกว่าที่นโยบาย Retention ระบุไว้มาก

Backup เก่านับเป็นข้อมูลที่ต้องลบด้วยหรือไม่

นับ เพราะ Backup ก็คือสำเนาของข้อมูลเดิม นโยบาย Data Retention ที่ดีควรระบุรอบการหมุนเวียน (rotation) ของ Backup ไว้ด้วย ไม่ใช่ระบุแค่ระยะเวลาที่เก็บในฐานข้อมูล production เพียงอย่างเดียว มิเช่นนั้นข้อมูลที่ถูกลบไปแล้วอาจกลับมาอยู่ในระบบอีกครั้งเมื่อมีการกู้คืน Backup

แพลตฟอร์มอย่าง trusty ช่วยตรงไหนและช่วยไม่ได้ตรงไหน

trusty ช่วยสแกนเว็บไซต์และหน้า Landing Page ของ SaaS เพื่อดู Cookie, Tracking Script และสถานะ Consent ที่ทำงานอยู่จริง ช่วยจัดหมวดเบื้องต้นเป็น Necessary, Functional, Analytics และ Marketing และช่วยร่าง Privacy Policy จากผลสแกนรวมกับข้อมูลที่ทีมกรอกเพิ่ม ส่วนนี้ใช้งานได้จริงในผลิตภัณฑ์ปัจจุบัน (Capability Status A)

แพลตฟอร์มอย่าง trusty ช่วยจัดการ TTL ในฐานข้อมูลได้หรือไม่

ไม่ได้ trusty ช่วยสแกน Cookie, Tracking Script และ Consent บนเว็บไซต์การตลาดเท่านั้น ส่วน TTL ในฐานข้อมูลและรอบ Backup ยังเป็นความรับผิดชอบของทีม Engineering และ Infrastructure โดยตรง สิ่งที่แพลตฟอร์มมองไม่เห็นคือ TTL ในฐานข้อมูล รอบ Backup ของทีม Infrastructure และสัญญากับ Subprocessor แต่ละราย ส่วนเหล่านี้ยังต้องให้ทีม Engineering และ Privacy ทำงานร่วมกันตามนโยบายภายใน แพลตฟอร์มเป็นตัวช่วยให้เห็นภาพรวมฝั่งเว็บไซต์ ไม่ใช่เครื่องมือที่จัดการฐานข้อมูลแทนทีมวิศวกร

เมื่อไรควรเปลี่ยนจากทำเองมาใช้แพลตฟอร์ม

ทีมขนาดเล็กที่มีเว็บไซต์เดียวและวิศวกรพร้อมดูแล TTL เองมักไม่จำเป็นต้องเปลี่ยนทันที สัญญาณที่บ่งชี้ว่าถึงเวลาต้องพิจารณาแพลตฟอร์มคือเมื่อบริษัทเริ่มมีหลายผลิตภัณฑ์หรือหลาย Landing Page ที่ทีมการตลาดดูแลเอง เมื่อลูกค้าองค์กรเริ่มถามคำถามเรื่อง Data Retention ระหว่างขั้นตอนจัดซื้อ หรือเมื่อไม่มีใครในทีมตอบได้ทันทีว่า Cookie หรือ Tracking Script ตัวไหนทำงานอยู่บนเว็บไซต์บ้าง

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

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

• ทำ Data Inventory แยกตามระบบ ฐานข้อมูล Analytics Log และ Subprocessor
• กำหนดระยะเวลา Retention แยกตามประเภทข้อมูล ไม่ใช้ตัวเลขเดียวทั้งระบบ
• ตั้ง TTL หรือ Cron Job ลบข้อมูลเก่าในฐานข้อมูลหลัก พร้อมทดสอบว่าทำงานจริง
• ระบุรอบการหมุนเวียนของ Backup ในนโยบาย ไม่ใช่ระบุแค่ระยะเวลาบนฐานข้อมูล production
• ตรวจสอบ Cookie และ Tracking Script บนเว็บไซต์การตลาดว่าทำงานตาม Consent
• ทำรายชื่อ Subprocessor และตรวจสอบระยะเวลาเก็บข้อมูลของแต่ละราย
• ให้ทีม Engineering, Product และ Privacy ทบทวนนโยบายร่วมกันทุกไตรมาส
• บันทึกวันที่ตรวจสอบล่าสุดและเวอร์ชันของนโยบายไว้ในเอกสารกลางที่ทุกทีมเข้าถึงได้

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

• ตั้ง TTL เฉพาะฐานข้อมูลหลัก แต่ลืมว่า Backup และ Data Warehouse ยังเก็บสำเนาไว้
• ทีม Growth ติดตั้ง Marketing Pixel หรือ Session Replay Tool โดยไม่แจ้งทีม Privacy
• ใช้ฟีเจอร์ลบข้อมูลของ Analytics Tool ตัวเดียว แล้วเข้าใจว่าครอบคลุมทุกระบบ
• ไม่มีรายชื่อ Subprocessor ที่เป็นปัจจุบัน ทำให้ตอบคำถามลูกค้าองค์กรไม่ได้
• ปล่อยให้ Engineering กับ Privacy ตั้งค่า Retention แยกกันโดยไม่เคยคุยกัน

สรุป

SaaS ที่มีทีมวิศวกรพร้อมอยู่แล้วสามารถเริ่มทำเองผ่าน TTL และ Cron Job ได้ แต่ต้องระวังจุดบอดเรื่อง Backup และ Subprocessor ที่มักถูกมองข้าม ส่วนการใช้แพลตฟอร์มอย่าง trusty ช่วยให้ทีม Privacy เห็นภาพรวมฝั่งเว็บไซต์และ Consent ได้เร็วขึ้น แต่ไม่ทดแทนการตั้งค่าฐานข้อมูลและนโยบาย Backup ที่ทีม Engineering ต้องดูแลเอง อ่านเพิ่มเติมที่ คู่มือ Data Retention สำหรับ SaaS และภาพรวมทั้งหมดที่ ศูนย์ความรู้ Data Governance

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

• NIST Privacy Framework
• แนวทาง Data Retention สำหรับองค์กรความเสี่ยงสูง