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

การ Audit Vendor Management ขององค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูงต้องตรวจสามชั้นคู่กันคือ รายชื่อ vendor ที่มีอยู่จริงตรงกับสัญญาและแบบสอบถามความปลอดภัยที่เก็บไว้หรือไม่ เงื่อนไขในสัญญา DPA ครอบคลุมทั้ง sub-processor และขั้นตอน offboarding หรือไม่ และมีหลักฐานการติดตามตรวจสอบ vendor ตามรอบที่ auditor ภายนอกตรวจสอบย้อนหลังได้หรือไม่

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

ทำไม vendor management ขององค์กรการเงินและประกันต้อง audit เข้มกว่าธุรกิจทั่วไป

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

ขั้นตอนที่ 1: ตรวจสอบว่ารายชื่อ vendor ที่มีอยู่ครบถ้วนตรงกับความเป็นจริง

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

ขั้นตอนที่ 2: ตรวจสอบสัญญา DPA และเงื่อนไขที่บังคับใช้ได้จริง

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

ขั้นตอนที่ 3: ตรวจสอบรายชื่อ sub-processor ที่ vendor หลักส่งข้อมูลต่อ

vendor หลักที่องค์กรเซ็นสัญญาด้วยมักไม่ได้ประมวลผลข้อมูลด้วยตัวเองทั้งหมด แต่ส่งต่อบางส่วนของงานให้ sub-processor รายอื่นอีกทอดหนึ่ง เช่น บริษัทที่รับจ้างประเมินความเสี่ยงด้านเครดิตอาจใช้ผู้ให้บริการ cloud storage ต่างประเทศเก็บข้อมูลดิบ ผู้ตรวจสอบควรขอรายชื่อ sub-processor ทั้งหมดจาก vendor หลัก พร้อมตรวจสอบว่าสัญญาระหว่างองค์กรกับ vendor หลักมีเงื่อนไขบังคับให้แจ้งล่วงหน้าก่อนเพิ่ม sub-processor รายใหม่หรือไม่ และ vendor หลักมีสัญญาที่ผูกมัด sub-processor ให้ปฏิบัติตามมาตรฐานเดียวกันหรือไม่ ช่องว่างที่พบบ่อยคือองค์กรรู้จักเฉพาะ vendor หลักที่เซ็นสัญญาด้วยโดยตรง แต่ไม่เคยเห็นรายชื่อ sub-processor ทั้งหมดที่แท้จริงเข้าถึงข้อมูล

ขั้นตอนที่ 4: ตรวจสอบผลแบบสอบถามความปลอดภัยย้อนหลัง

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

ขั้นตอนที่ 5: ตรวจสอบหลักฐานการติดตามตรวจสอบ vendor ตามรอบ

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

ขั้นตอนที่ 6: ตรวจสอบกระบวนการ offboarding เมื่อสิ้นสุดสัญญา

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

ขั้นตอนที่ 7: ตรวจสอบว่าทีมที่เกี่ยวข้องเข้าใจขอบเขตความรับผิดชอบตรงกัน

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

Evidence ที่ควรเก็บไว้เพื่อรองรับการตรวจสอบ

• ทะเบียน vendor ที่รวมทั้งสามแหล่ง (จัดซื้อ Privacy และไอที) พร้อมวันที่กระทบยอดล่าสุด
• สำเนาสัญญา DPA ฉบับล่าสุดของแต่ละราย พร้อมวันที่ทบทวน
• รายชื่อ sub-processor ของแต่ละ vendor หลัก พร้อมหลักฐานการแจ้งเตือนเมื่อมีการเปลี่ยนแปลง
• ผลแบบสอบถามความปลอดภัยฉบับล่าสุดพร้อมวันที่ตอบ ไม่เกิน 12 เดือน
• บันทึกการติดตามตรวจสอบและเหตุการณ์ผิดปกติที่ vendor เคยแจ้ง
• หลักฐานยืนยันการคืน/ลบข้อมูลเมื่อสิ้นสุดสัญญาของ vendor แต่ละราย

วิธีจัดลำดับความสำคัญเมื่อพบ vendor ที่มีความเสี่ยงสูงหลายรายพร้อมกัน

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

บทบาทของคณะกรรมการตรวจสอบภายในต่อผลการ audit vendor management

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

ข้อผิดพลาดที่พบบ่อยระหว่างรอบตรวจสอบจริง

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

ตัวอย่างสิ่งที่ auditor ภายนอกมักขอดูก่อนออกความเห็น

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

ความถี่ของรอบตรวจสอบเทียบกับขนาดและความเสี่ยงขององค์กร

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

สรุป: audit ที่ดีต้องตรวจทั้งสัญญา ระบบจริง และหลักฐาน

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

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

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