วิธี Audit Data Inventory ขององค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูง พร้อม Evidence ที่ควรเก็บ

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

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

ทำไม Data Inventory ขององค์กรการเงินและประกันต้องกว้างกว่าแค่เว็บไซต์

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

ความแตกต่างนี้สำคัญมากสำหรับหัวข้อการ Audit เพราะถ้าทีมงานเข้าใจผิดว่า Data Inventory คือแค่รายการคุกกี้บนเว็บไซต์ การตรวจสอบก็จะครอบคลุมแค่เศษเสี้ยวของความเสี่ยงจริงที่องค์กรมี

โครงสร้าง Audit ตามแนวทาง NIST Privacy Framework

NIST Privacy Framework วางโครงสร้างการจัดการความเป็นส่วนตัวไว้เป็นฟังก์ชันหลักที่องค์กรใช้อ้างอิงได้ เช่น การระบุ (Identify) ว่าองค์กรมีข้อมูลอะไรบ้างและมีความเสี่ยงอย่างไร การกำกับดูแล (Govern) ที่กำหนดนโยบายและความรับผิดชอบ และการควบคุม (Control) ที่ดูแลว่าข้อมูลถูกใช้ตามวัตถุประสงค์ที่กำหนดไว้จริง เมื่อนำมาปรับใช้กับการ Audit Data Inventory ขององค์กรการเงินและประกัน ทีมงานสามารถใช้โครงสร้างนี้เป็นแกนตรวจสอบได้ว่าในแต่ละฟังก์ชัน องค์กรมีหลักฐานรองรับเพียงพอหรือไม่ ตัวอย่างเช่นในฟังก์ชันการระบุ ต้องตรวจว่ารายการหมวดข้อมูลที่บันทึกไว้ยังครบถ้วนตามระบบงานปัจจุบัน ในฟังก์ชันการกำกับดูแล ต้องตรวจว่ามีผู้รับผิดชอบชัดเจนต่อแต่ละหมวดข้อมูล และในฟังก์ชันการควบคุม ต้องตรวจว่าสิทธิ์การเข้าถึงข้อมูลยังตรงกับหน้าที่งานจริงของพนักงานแต่ละคน

ขั้นตอนตรวจสอบ Data Inventory ประจำงวด

ขั้นที่ 1: เทียบรายการระบบงานที่มีจริงกับบันทึกที่มีอยู่

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

ขั้นที่ 2: ตรวจสอบเส้นทางไหลของข้อมูลแต่ละหมวด

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

ขั้นที่ 3: ตรวจสอบระยะเวลาเก็บข้อมูลเทียบกับที่ระบุไว้จริง

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

ขั้นที่ 4: ตรวจสอบสิทธิ์เข้าถึงข้อมูลของพนักงานและผู้ประมวลผลภายนอก

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

ขั้นที่ 5: ทดสอบว่าองค์กรตอบคำขอสิทธิ์เจ้าของข้อมูลได้จริงภายในเวลาที่กำหนด

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

การเชื่อมโยง Data Inventory กับการแจ้งเหตุละเมิดข้อมูล

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

ตัวอย่างหมวดข้อมูลและระยะเวลาเก็บที่ควรตรวจซ้ำในองค์กรการเงินและประกัน

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

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

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

เครื่องมือที่ใช้ดูแล Data Inventory: สเปรดชีตยังพอไหวหรือต้องใช้ระบบเฉพาะ

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

ข้อผิดพลาดที่พบบ่อยเมื่อ Audit Data Inventory ในองค์กรการเงินและประกัน

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

บทสรุป: Audit Data Inventory คือวงจรต่อเนื่อง ไม่ใช่เอกสารที่ทำครั้งเดียว

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

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

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