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

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

Vendor Management คืออะไร และทำไมองค์กรการเงินต้องให้ความสำคัญเป็นพิเศษ

Vendor Management ในบริบทของการคุ้มครองข้อมูลส่วนบุคคล หมายถึงกระบวนการคัดเลือก ตรวจสอบ ทำสัญญา และติดตามผู้ให้บริการภายนอกหรือผู้ประมวลผลข้อมูล (processor) ที่เข้าถึง ประมวลผล หรือจัดเก็บข้อมูลส่วนบุคคลแทนองค์กร ตั้งแต่ผู้ให้บริการคลาวด์ ระบบ CRM บริษัทรับส่งเอกสาร ไปจนถึงที่ปรึกษาด้าน Actuarial หรือผู้ตรวจสอบเคลม สำหรับองค์กรการเงินและประกันภัย ความเสี่ยงจากผู้ให้บริการภายนอกสูงกว่าธุรกิจทั่วไปด้วยเหตุผลสามข้อ ข้อแรกคือปริมาณและความอ่อนไหวของข้อมูล เช่น ข้อมูลบัญชี ข้อมูลสุขภาพประกอบการเคลม หรือข้อมูลเครดิต ข้อสองคือห่วงโซ่ผู้ให้บริการมักมีหลายชั้น ผู้ประมวลผลรายหนึ่งอาจส่งต่องานให้ sub-processor อีกหลายราย และข้อสามคือหน่วยงานกำกับดูแลภาคการเงินมักตรวจสอบความรับผิดชอบต่อบุคคลที่สามอย่างเข้มงวดเป็นพิเศษ เพราะความเสียหายจากข้อมูลรั่วไหลในภาคนี้ส่งผลกระทบต่อความเชื่อมั่นของระบบการเงินโดยรวม

บทความนี้วางกรอบการทำงานเป็น 5 ขั้นตอนที่ทีม Legal, Privacy, Security และ Compliance สามารถนำไปปรับใช้ได้จริง โดยแต่ละขั้นตอนมีตัวอย่างเอกสารและ Evidence ที่ควรเก็บไว้เพื่อพร้อมรับการตรวจสอบ

ขั้นตอนที่ 1: จัดทำ Vendor Inventory และจัดระดับความเสี่ยง

จุดเริ่มต้นของระบบ Vendor Management ที่ใช้งานได้จริงคือการรู้ว่าองค์กรมีผู้ให้บริการภายนอกกี่รายที่แตะต้องข้อมูลส่วนบุคคล หลายองค์กรมีรายชื่อผู้ขายในระบบจัดซื้อ แต่ไม่มีการทำเครื่องหมายว่ารายใดเข้าถึงข้อมูลส่วนบุคคลบ้าง ขั้นตอนแรกจึงต้องเชื่อมข้อมูลจากฝ่ายจัดซื้อ ฝ่าย IT และเจ้าของระบบแต่ละหน่วยงาน เพื่อสร้าง Vendor Inventory ที่ครอบคลุมอย่างน้อยดังนี้ ชื่อผู้ให้บริการและประเภทบริการ ประเภทข้อมูลส่วนบุคคลที่เข้าถึง ปริมาณและความอ่อนไหวของข้อมูล ช่องทางการเข้าถึงระบบ และประเทศที่ประมวลผลข้อมูล เมื่อมี Inventory ครบแล้ว ให้จัดระดับความเสี่ยงเป็นอย่างน้อยสามระดับ เช่น High สำหรับผู้ให้บริการที่เข้าถึงข้อมูลอ่อนไหวจำนวนมากหรือมีสิทธิ์เข้าถึงระบบแกนหลัก Medium สำหรับผู้ให้บริการที่เข้าถึงข้อมูลบางส่วนภายใต้การควบคุม และ Low สำหรับผู้ให้บริการที่ไม่แตะต้องข้อมูลส่วนบุคคลเลยหรือแตะต้องน้อยมาก การจัดระดับนี้จะกำหนดความเข้มข้นของ Due Diligence ในขั้นตอนถัดไป เพราะทรัพยากรของทีม Privacy มีจำกัด การทุ่มเวลาตรวจสอบผู้ให้บริการทุกรายเท่ากันไม่ใช่แนวทางที่ยั่งยืน

ขั้นตอนที่ 2: Due Diligence และ Security Questionnaire ก่อนเซ็นสัญญา

ก่อนลงนามในสัญญากับผู้ให้บริการรายใหม่ที่จัดอยู่ในระดับความเสี่ยง Medium ขึ้นไป ทีมจัดซื้อควรกำหนดให้ผ่านขั้นตอน Due Diligence ที่มีเอกสารรองรับ ไม่ใช่การถามด้วยวาจาแล้วจดจำเอง แบบสอบถามความมั่นคงปลอดภัย (Security Questionnaire) ควรครอบคลุมประเด็นสำคัญ เช่น มาตรการควบคุมการเข้าถึงข้อมูล การเข้ารหัสข้อมูลทั้งขณะส่งและขณะจัดเก็บ นโยบายการแจ้งเหตุการณ์ข้อมูลรั่วไหลและกรอบเวลาที่จะแจ้งองค์กร การมีใบรับรองมาตรฐานที่เกี่ยวข้อง เช่น ISO 27001 หรือ SOC 2 และรายชื่อ sub-processor ที่ผู้ให้บริการจะใช้ต่อ สำหรับผู้ให้บริการระดับ High ควรพิจารณาขอเอกสารเพิ่มเติม เช่น รายงานผลการทดสอบเจาะระบบล่าสุด หรือสรุปผลการตรวจสอบภายในด้าน Security ที่ผ่านมา คำตอบทั้งหมดควรถูกเก็บเป็นหลักฐานในระบบจัดซื้อหรือระบบ GRC เพื่อให้สามารถย้อนดูได้ว่าตัดสินใจอนุมัติผู้ให้บริการรายนั้นบนพื้นฐานอะไร หากพบว่าคำตอบไม่ครบถ้วนหรือมีความเสี่ยงสูงเกินกว่าที่ยอมรับได้ ทีม Privacy และ Security ควรมีอำนาจยับยั้งการเซ็นสัญญาจนกว่าจะได้รับการแก้ไข ไม่ใช่ปล่อยให้ฝ่ายจัดซื้อตัดสินใจเพียงลำพัง

ขั้นตอนที่ 3: เงื่อนไข DPA และ Sub-processor ที่ต้องมีในสัญญา

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

ขั้นตอนที่ 4: การติดตามตรวจสอบระหว่างสัญญา

Vendor Management ที่ดีไม่จบลงที่การเซ็นสัญญา เพราะความเสี่ยงของผู้ให้บริการเปลี่ยนแปลงได้ตลอดอายุสัญญา องค์กรควรกำหนดรอบการติดตามตามระดับความเสี่ยง เช่น ผู้ให้บริการระดับ High ทบทวนทุก 6-12 เดือน ผู้ให้บริการระดับ Medium ทบทวนทุก 12-18 เดือน และผู้ให้บริการระดับ Low ทบทวนทุก 24 เดือนหรือเมื่อมีการเปลี่ยนแปลงขอบเขตบริการ การติดตามควรรวมถึงการขอเอกสารรับรองมาตรฐานความมั่นคงปลอดภัยฉบับล่าสุด การทบทวนรายชื่อ sub-processor ว่ามีการเปลี่ยนแปลงหรือไม่ การตรวจสอบว่าผู้ให้บริการเคยมีเหตุการณ์ข้อมูลรั่วไหลที่กระทบองค์กรอื่นในช่วงที่ผ่านมาหรือไม่ และการประเมินซ้ำว่าระดับความเสี่ยงเดิมยังเหมาะสมอยู่หรือต้องปรับขึ้น ตัวอย่างเช่น หากผู้ให้บริการที่เคยจัดอยู่ระดับ Medium เริ่มได้รับสิทธิ์เข้าถึงข้อมูลเพิ่มเติมจากการขยายขอบเขตงาน ทีม Privacy ควรพิจารณาย้ายไปอยู่ระดับ High และกำหนดให้ผ่าน Due Diligence รอบใหม่ ทุกรอบการติดตามควรมีบันทึกผลเป็นลายลักษณ์อักษรเก็บไว้ในระบบ GRC เพื่อเป็นหลักฐานว่าการกำกับดูแลไม่ได้หยุดอยู่แค่วันเซ็นสัญญา

ขั้นตอนที่ 5: กระบวนการ Offboarding และการคืนหรือลบข้อมูลเมื่อสิ้นสุดสัญญา

เมื่อสัญญากับผู้ให้บริการสิ้นสุดลง ไม่ว่าจะด้วยเหตุผลใดก็ตาม องค์กรต้องมีกระบวนการ Offboarding ที่ชัดเจนเพื่อปิดความเสี่ยงจากข้อมูลที่ยังค้างอยู่ในมือผู้ให้บริการเดิม ขั้นตอนที่ควรมีได้แก่ การแจ้งเป็นลายลักษณ์อักษรถึงการสิ้นสุดสัญญาและกำหนดระยะเวลาที่ผู้ให้บริการต้องดำเนินการ การเพิกถอนสิทธิ์การเข้าถึงระบบและบัญชีผู้ใช้ทั้งหมดที่เกี่ยวข้อง การขอให้ผู้ให้บริการยืนยันการคืนข้อมูลในรูปแบบที่องค์กรกำหนด หรือลบข้อมูลอย่างถาวรพร้อมออกหนังสือรับรองการลบ (Certificate of Data Destruction) และการตรวจสอบว่า sub-processor ที่เคยได้รับข้อมูลต่อจากผู้ให้บริการหลักได้ดำเนินการลบหรือคืนข้อมูลเช่นเดียวกัน หนังสือรับรองการลบข้อมูลนี้ควรถูกเก็บไว้เป็น Evidence ถาวรในแฟ้ม Vendor Management ขององค์กร แม้ว่าความสัมพันธ์ทางธุรกิจจะสิ้นสุดไปแล้วก็ตาม เพราะหากเกิดข้อพิพาทหรือการตรวจสอบย้อนหลัง องค์กรจำเป็นต้องแสดงได้ว่าได้ปิดความเสี่ยงจากผู้ให้บริการรายนั้นอย่างสมบูรณ์

ตัวอย่างตารางจัดระดับความเสี่ยงผู้ให้บริการ

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

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

องค์กรจำนวนมากเริ่มต้นวางระบบ Vendor Management ด้วยความตั้งใจดี แต่มักพลาดในจุดที่คล้ายกันซ้ำแล้วซ้ำเล่า ข้อผิดพลาดแรกคือการจัดทำ Inventory เพียงครั้งเดียวแล้วไม่อัปเดต ทำให้เมื่อเวลาผ่านไปหนึ่งหรือสองปี รายชื่อผู้ให้บริการจริงกับรายชื่อในระบบไม่ตรงกัน ข้อผิดพลาดที่สองคือการใช้ Security Questionnaire ชุดเดียวกับผู้ให้บริการทุกระดับความเสี่ยง ทำให้ทีมงานเสียเวลากับผู้ให้บริการความเสี่ยงต่ำโดยไม่จำเป็น ในขณะที่ผู้ให้บริการความเสี่ยงสูงอาจไม่ได้รับการตรวจสอบลึกพอ ข้อผิดพลาดที่สามคือการเซ็นสัญญาโดยไม่มี DPA แนบท้าย หรือใช้ DPA ฉบับเก่าที่ไม่ครอบคลุมเงื่อนไข sub-processor ข้อผิดพลาดที่สี่คือการไม่มีเจ้าของกระบวนการ (process owner) ที่ชัดเจน ทำให้เมื่อสัญญาใกล้หมดอายุ ไม่มีใครรับผิดชอบเรื่องการต่อสัญญาหรือ Offboarding และข้อผิดพลาดที่ห้าคือการมองว่า Vendor Management เป็นงานของฝ่ายจัดซื้อเพียงฝ่ายเดียว ทั้งที่ควรเป็นความร่วมมือระหว่างฝ่ายจัดซื้อ ฝ่ายกฎหมาย ฝ่าย Security และฝ่าย Privacy ตั้งแต่ต้นจนจบกระบวนการ

สรุป

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

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

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