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

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

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

บทความนี้อธิบายแนวทางเชิงปฏิบัติสำหรับองค์กรขององค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูง เท่านั้น ไม่ใช่คำแนะนำทางกฎหมายเฉพาะกรณี แต่ละองค์กรควรปรึกษาที่ปรึกษาด้านการกำกับดูแลข้อมูลของตนเองประกอบการตัดสินใจ

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

สำหรับองค์กรที่ใช้ระบบ Core Banking ระบบยืนยันตัวตนลูกค้า (KYC/eKYC) และคลังข้อมูลองค์กร (data warehouse)เชื่อมต่อกันหลายระบบ ข้อมูลมักไหลผ่านหลายจุดก่อนถึงปลายทางสุดท้าย เช่น ข้อมูลที่กรอกในฟอร์มหน้าเว็บอาจถูกส่งต่อไปยังระบบ CRM แล้วซิงก์ต่อไปยังระบบบัญชีหรือระบบการตลาด Data Mapping ช่วยให้ทีม Compliance, Risk และ IT ขององค์กรการเงินและประกันเห็นภาพเส้นทางเหล่านี้ทั้งหมดในแผนภาพเดียว

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

Data Mapping ต่างจาก Data Inventory อย่างไร

Data Mapping ต่างจาก Data Inventory อย่างไร เป็นคำถามที่มักเกิดขึ้นเมื่อองค์กรเริ่มวางแผนบริหารจัดการข้อมูลอย่างเป็นระบบ

Data Mapping ที่แม่นยำต้องอาศัย Data Inventory ที่ครบถ้วนเป็นจุดตั้งต้น หากบัญชีข้อมูลไม่ครบ แผนภาพการไหลของข้อมูลก็จะขาดจุดสำคัญไปด้วย

โครงสร้าง Data Mapping ที่องค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูงควรมี

จุดเริ่มต้นของข้อมูล

ควรระบุว่าข้อมูลแต่ละประเภทถูกเก็บครั้งแรกที่จุดใด เช่น ฟอร์มบนเว็บไซต์ แอปพลิเคชัน หรือระบบภายในระบบ Core Banking ระบบยืนยันตัวตนลูกค้า (KYC/eKYC) และคลังข้อมูลองค์กร (data warehouse)

จุดที่ข้อมูลถูกประมวลผลหรือส่งต่อ

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

จุดสิ้นสุดของข้อมูล

ควรระบุว่าข้อมูลสิ้นสุดที่ระบบจัดเก็บถาวรใด หรือถูกลบทิ้งเมื่อใด ตามนโยบายเก็บรักษาข้อมูลขององค์กร

ห้ามทำ Data Mapping โดยไม่ตรวจสอบกับทีมเทคนิคที่ดูแลระบบจริง เพราะเส้นทางการไหลของข้อมูลที่เข้าใจจากเอกสารอาจไม่ตรงกับสิ่งที่ระบบทำงานจริง โดยเฉพาะเมื่อมีการเชื่อมต่อกับบริการภายนอกหลายราย

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

1. เริ่มจาก Data Inventory ที่มีอยู่แล้ว เพื่อใช้เป็นรายการข้อมูลตั้งต้น
2. สัมภาษณ์ทีมเทคนิคที่ดูแลแต่ละระบบเพื่อยืนยันเส้นทางการไหลของข้อมูลจริง
3. วาดแผนภาพแสดงจุดเริ่มต้น จุดประมวลผล และจุดสิ้นสุดของข้อมูลแต่ละประเภท
4. ระบุจุดที่ข้อมูลถูกส่งออกไปยังบริการภายนอกหรือผู้ให้บริการรายที่สาม
5. ตรวจสอบแผนภาพกับทีมเทคนิคอีกครั้งเพื่อยืนยันความถูกต้อง
6. ทบทวนและปรับปรุง Data Mapping ทุกครั้งที่มีการเปลี่ยนแปลงระบบหรือเพิ่มการเชื่อมต่อใหม่

การตรวจสอบและเก็บหลักฐาน (Audit และ Evidence)

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

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

การเก็บรักษา ความปลอดภัย และการทบทวนเป็นระยะ

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

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

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

สถานการณ์ที่พบบ่อยในทางปฏิบัติ

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

เมื่อทีมงานเพิ่งเริ่มต้นวางกระบวนการ

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

สิ่งที่มักเกิดขึ้นเมื่อยังไม่มีกระบวนการที่ชัดเจน

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

แนวทางป้องกันปัญหาในระยะยาว

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

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

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

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

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

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

สรุป

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

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

• NIST Privacy Framework