วิธีวางระบบ Data Retention สำหรับองค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูงแบบเป็นขั้นตอน

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

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

ขั้นตอนที่ 1: จัดหมวดหมู่ข้อมูลตามความอ่อนไหวและวัตถุประสงค์

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

ขั้นตอนที่ 2: กำหนดระยะเวลาเก็บต่อประเภทข้อมูล พร้อมเหตุผลอ้างอิงที่ตรวจสอบย้อนหลังได้

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

ขั้นตอนที่ 3: เลือกกลไกจัดการเมื่อครบกำหนดระยะเวลาเก็บ

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

ขั้นตอนที่ 4: ตั้งค่าระบบลบอัตโนมัติในระบบหลัก

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

ขั้นตอนที่ 5: ครอบคลุม backup และไฟล์นอกระบบหลัก

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

ขั้นตอนที่ 6: ผูกเงื่อนไขระยะเวลาเก็บกับ vendor และผู้ประมวลผลภายนอก

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

ขั้นตอนที่ 7: ทดสอบกระบวนการและเก็บหลักฐานยืนยันการลบ

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

กำหนดเจ้าของงานให้ชัดเจนในแต่ละขั้นตอน

ทั้ง 7 ขั้นตอนข้างต้นจะล่มไม่เป็นท่าถ้าไม่มีใครรับผิดชอบชัดเจนว่าใครทำอะไร ฝ่ายกฎหมายควรเป็นเจ้าของขั้นตอนที่ 1 และ 2 เพราะต้องตัดสินใจเรื่องหมวดหมู่และระยะเวลาเก็บตามหลักกฎหมาย ฝ่ายไอทีควรเป็นเจ้าของขั้นตอนที่ 4 และ 5 เพราะต้องตั้งค่าระบบจริงและตรวจสอบ backup ฝ่ายจัดซื้อร่วมกับฝ่ายกฎหมายควรเป็นเจ้าของขั้นตอนที่ 6 เรื่อง vendor ส่วนขั้นตอนที่ 3 เรื่องเลือกกลไกจัดการควรเป็นการตัดสินใจร่วมกันระหว่างฝ่ายกฎหมายและฝ่ายธุรกิจ เพราะมีทั้งมิติความเสี่ยงและมิติต้นทุนเข้ามาเกี่ยวข้อง การเขียนตาราง RACI ที่ระบุว่าใครรับผิดชอบหลัก ใครต้องได้รับแจ้ง และใครต้องอนุมัติในแต่ละขั้นตอน ช่วยลดปัญหาที่งานตกหล่นระหว่างแผนกได้มาก โดยเฉพาะในองค์กรขนาดใหญ่ที่มีหลายทีมเกี่ยวข้องพร้อมกัน

ตัวอย่าง: องค์กรสินเชื่อรายย่อยวางระบบ Data Retention ภายใน 90 วัน

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

เมื่อวางระบบเสร็จแล้ว ต้องตรวจสอบซ้ำเป็นรอบ

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

เครื่องมือที่ช่วยให้แต่ละขั้นตอนทำได้เร็วขึ้น

องค์กรที่มีทีมไอทีขนาดใหญ่มักใช้ระบบจัดการวงจรชีวิตข้อมูล (data lifecycle management tool) ที่ผูกกับฐานข้อมูลหลักโดยตรง เพื่อให้ตั้งค่ากฎการลบหรือ anonymize ได้จากหน้าจอเดียว แทนที่จะเข้าไปตั้งค่าทีละระบบด้วยมือ ส่วนองค์กรขนาดกลางที่ยังไม่มีเครื่องมือเฉพาะทาง อาจเริ่มจากสคริปต์ที่รันตามรอบเวลาที่กำหนดในระบบฐานข้อมูลที่มีอยู่แล้วก่อน แล้วค่อยลงทุนเครื่องมือเฉพาะทางเมื่อจำนวนระบบและปริมาณข้อมูลเพิ่มขึ้นจนการจัดการด้วยสคริปต์เริ่มไม่ทันการณ์ สิ่งที่สำคัญกว่าเครื่องมือคือกระบวนการตรวจสอบว่ากฎที่ตั้งไว้ยังทำงานถูกต้องอยู่เสมอ เพราะเครื่องมือที่ดีที่สุดก็ไร้ประโยชน์ถ้าไม่มีใครตรวจสอบผลลัพธ์ว่าตรงกับที่ตั้งใจไว้จริงหรือไม่

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

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

สรุปวิธีวางระบบ Data Retention

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

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

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