Data Inventory คืออะไร? คู่มือจัดทำบัญชีข้อมูลสำหรับองค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูง

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

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

ข้อมูลประเภทใดที่องค์กรการเงินต้องขึ้นทะเบียนเป็นพิเศษ

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

ระบบที่มักเป็นแหล่งเก็บข้อมูลกลุ่มนี้ ได้แก่ ระบบ Core Banking ระบบยืนยันตัวตนลูกค้า และคลังข้อมูลองค์กร (data warehouse) ที่รวบรวมข้อมูลจากหลายระบบย่อยเข้าด้วยกัน การไล่ตรวจว่าคลังข้อมูลกลางมีข้อมูลอะไรไหลเข้ามาจากระบบใดบ้าง มักเป็นจุดที่ใช้เวลานานที่สุดในการทำ Data Inventory ขององค์กรขนาดใหญ่

ระดับชั้นความลับของข้อมูลที่ควรกำหนดใน Data Inventory

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

การผูก Data Inventory เข้ากับ Audit Trail สำหรับผู้ตรวจสอบ

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

1. ไล่สำรวจระบบที่เก็บข้อมูลลูกค้าทั้งหมด เริ่มจาก Core Banking แล้วขยายไปยังระบบย่อยที่เชื่อมต่อ
2. จัดระดับชั้นความลับของข้อมูลแต่ละประเภทตามตารางด้านบน
3. ระบุเจ้าของข้อมูล (data owner) และผู้ดูแลระบบ (system custodian) ของแต่ละระบบให้ชัดเจน
4. เชื่อมโยง Data Inventory กับ log การเข้าถึงของแต่ละระบบ เพื่อให้ดึงรายงานย้อนหลังได้
5. ทดสอบดึงรายงานตัวอย่างก่อนการตรวจสอบจริง เพื่อยืนยันว่าข้อมูลครบและตรงกับสิ่งที่ผู้ตรวจสอบจะถาม
6. ทบทวน Data Inventory ทุกครั้งที่มีการเพิ่มระบบใหม่หรือเปลี่ยนพันธมิตรที่รับข้อมูล

การแชร์ข้อมูลกับบุคคลที่สามในธุรกิจการเงิน

องค์กรการเงินมักต้องแชร์ข้อมูลลูกค้ากับบุคคลที่สามหลายประเภท เช่น เครดิตบูโรสำหรับตรวจสอบประวัติสินเชื่อ พันธมิตรประกันสำหรับผลิตภัณฑ์ bancassurance หรือผู้ให้บริการภายนอกที่รับ outsource กระบวนการยืนยันตัวตน (KYC) แต่ละความสัมพันธ์เหล่านี้ควรถูกบันทึกไว้ใน Data Inventory พร้อมระบุว่าส่งข้อมูลอะไรไปให้ ด้วยวัตถุประสงค์ใด และมีข้อตกลงการประมวลผลข้อมูล (DPA) รองรับหรือไม่

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

เครื่องมือที่เหมาะกับองค์กรขนาดใหญ่

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

ดูแนวทางจัดทำ Data Inventory ในภาพรวมของหมวดหมู่ data-governance เพิ่มเติมได้ที่ data-governance หรือดูคู่มือสำหรับธุรกิจสุขภาพเพื่อเทียบมุมมองที่ต่างออกไปได้ที่ คู่มือสำหรับธุรกิจสุขภาพ และประเมินความพร้อมด้านความน่าเชื่อถือของเว็บไซต์องค์กรได้ที่ Website Trust Scan

การเชื่อม Data Inventory เข้ากับการประเมินความเสี่ยงด้าน Model Risk

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

ฝ่าย Model Risk Management มักต้องการทราบว่าข้อมูลที่ใช้ฝึกโมเดลมาจากแหล่งใด ผ่านการประมวลผลอย่างไรก่อนเข้าโมเดล และมีการปรับปรุงหรือลบข้อมูลบางส่วนออกหรือไม่ คำถามเหล่านี้ตอบได้ง่ายขึ้นมากหากมี Data Inventory ที่เชื่อมโยงกับ data lineage คือเส้นทางการไหลของข้อมูลตั้งแต่ต้นทางจนถึงจุดที่ถูกใช้งานจริง แทนที่จะต้องสอบถามทีมพัฒนาโมเดลทีละคนว่าใช้ข้อมูลอะไรบ้าง

การผูก Data Inventory เข้ากับ data lineage ในระดับนี้ต้องอาศัยความร่วมมือระหว่างฝ่าย Data, ฝ่าย Compliance และฝ่าย Model Risk อย่างใกล้ชิด เพราะแต่ละฝ่ายมองข้อมูลชุดเดียวกันด้วยวัตถุประสงค์ต่างกัน การมีเวทีทบทวนร่วมกันเป็นระยะ เช่น การประชุมทบทวนการใช้ข้อมูลรายไตรมาส ช่วยให้ทุกฝ่ายเห็นภาพเดียวกันและลดความเสี่ยงที่ข้อมูลจะถูกนำไปใช้นอกเหนือขอบเขตที่เคยประเมินไว้

การเก็บรักษาหลักฐานสำหรับการตรวจสอบจากหน่วยงานกำกับดูแล

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

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

การรับมือเมื่อพบว่า Data Inventory ไม่ตรงกับสภาพจริง

สถานการณ์ที่พบได้บ่อยในองค์กรขนาดใหญ่คือเมื่อเริ่มทำ Data Inventory อย่างจริงจัง กลับพบว่ามีระบบที่เก็บข้อมูลลูกค้าอยู่นอกเหนือรายการที่เคยบันทึกไว้ เช่น ไฟล์ Excel ที่ทีมสาขาใช้เก็บข้อมูลลูกค้า VIP เป็นการภายใน หรือระบบทดลอง (proof of concept) ที่ทีมนวัตกรรมสร้างขึ้นแล้วนำข้อมูลลูกค้าจริงไปทดสอบโดยไม่ได้แจ้งฝ่าย Compliance สถานการณ์เหล่านี้ไม่ควรถูกมองว่าเป็นความล้มเหลว แต่เป็นสัญญาณว่าต้องปรับกระบวนการสื่อสารภายในให้ทุกทีมรู้ว่าต้องแจ้งฝ่าย Data Governance ก่อนเริ่มเก็บข้อมูลลูกค้าในระบบใหม่ทุกครั้ง

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

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

• แยกข้อมูล KYC ข้อมูลเครดิต และข้อมูลชีวมิติออกจากข้อมูลติดต่อทั่วไปใน Data Inventory
• จัดระดับชั้นความลับของข้อมูลทุกประเภทตามมาตรฐาน Public/Internal/Confidential/Restricted
• เชื่อมโยง Data Inventory กับ log การเข้าถึงของแต่ละระบบเพื่อรองรับการตรวจสอบ
• บันทึกความสัมพันธ์กับบุคคลที่สามทุกรายพร้อม DPA ที่รองรับ
• ทดสอบดึงรายงานตัวอย่างก่อนการตรวจสอบจริงอย่างน้อยปีละครั้ง

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

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

สรุป

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

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

• NIST Privacy Framework