การจัดการความเสี่ยงบุคคลที่สาม (TPRM) สำหรับ APAC

องค์กรยุคใหม่ไม่ได้มีแค่บริษัทเดียวของตัวเอง แต่คือโครงข่ายของ vendor, แพลตฟอร์ม SaaS, ผู้ให้บริการคลาวด์ และ integrator ที่แต่ละรายถือเส้นด้ายของข้อมูลและชื่อเสียงของคุณอยู่ในมือ เมื่อรายใดรายหนึ่งล้มเหลว ความล้มเหลวนั้นก็ตกเป็นของคุณทันที หน่วยงานกำกับดูแลถาม คุณ ว่าทำไม vendor ถึงผ่านการคัดกรองมาได้ และลูกค้าถาม คุณ ว่าทำไมข้อมูลของพวกเขาถึงรั่วไหลผ่าน supplier ที่คุณเลือกเอง

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

กับดักของ questionnaire #

โปรแกรม TPRM ส่วนใหญ่คือ spreadsheet ที่มีคำถาม 200 ถึง 500 ข้อ ส่งให้ vendor ทุกรายเท่า ๆ กัน แล้วเก็บเข้าแฟ้มลืม ๆ ไปจนถึงปีหน้า วิธีนี้สร้างงานเอกสารแต่ลดความเสี่ยงได้น้อยมาก ด้วยเหตุผลสองข้อ:

1. ทุก vendor ถูกปฏิบัติเหมือนกันหมด supplier กาแฟกับ payment processor ได้รับ questionnaire ชุดเดียวกัน ทั้งที่ระดับ exposure ต่างกันคนละโลก
2. เชื่อคำรับรองของ vendor เพียงอย่างเดียว vendor ที่ตอบว่า “เราเข้ารหัสข้อมูลนะ” ไม่เท่ากับ vendor ที่ พิสูจน์ให้ดูได้ questionnaire วัดความมั่นใจ ไม่ได้วัดมาตรการควบคุม

ทางแก้คือความเป็นธรรมสัดส่วนและการตรวจสอบยืนยัน จัดกลุ่ม vendor ตามสิทธิ์เข้าถึงที่เขามีจริง แล้วลงแรงตรวจเชิงลึกเฉพาะจุดที่ exposure มีตัวตน

จัดระดับตาม exposure จริง #

โมเดลที่ใช้งานได้จริงจัดระดับ vendor ตามสิ่งที่เขาแตะต้อง:

• Tier 1, วิกฤต: เก็บข้อมูล cardholder หรือข้อมูลส่วนบุคคล เชื่อมต่อกับระบบคุณลึก หรือเป็น single point of failure กลุ่มนี้ต้องได้รับ technical assessment, audit rights และ security schedule ผูกไว้ในสัญญา
• Tier 2, สำคัญ: process ข้อมูลธุรกิจหรือมีสิทธิ์ระดับ privileged กลุ่มนี้ใช้การ review เชิงเทคนิคแบบเบากว่าและ revalidate เป็นรอบ
• Tier 3, รายคราว: เข้าถึงข้อมูลจำกัดหรือไม่มีเลย ใช้ due diligence ระดับพื้นฐานเท่านี้ ไม่ต้องไปไกลกว่านั้น

ประเด็นไม่ใช่เพิ่ม process แต่คือ process ที่ ได้สัดส่วน payment gateway Tier 1 ที่ล้มคือ incident stationery vendor Tier 3 ที่ล้มคือความไม่สะดวกเท่านั้น การปฏิบัติทั้งคู่เหมือนกันคือการเทเวลาไปกับความเสี่ยงผิดฝั่ง

เลยไปกว่า questionnaire: การตรวจสอบเชิงเทคนิค #

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

• Review evidence: รายงาน SOC 2, certificate ISO 27001, PCI DSS AOC และที่สำคัญที่สุดคือ scope ของรายงานเหล่านั้น ไม่ใช่แค่โลโก้หน้าปก
• Architecture review: vendor จัดการข้อมูลของคุณจริง ๆ อย่างไรใน environment ของเขา ไม่ใช่แบบที่หน้า marketing เขาเขียนไว้
• เงื่อนไขสัญญาที่มีเขี้ยว: security schedule ที่บังคับใช้ได้ กำหนดเวลาแจ้ง breach และ audit rights ที่รอดจากการ renegotiate

framework ต่าง ๆ เห็นตรงกันในเรื่องนี้ NIST SP 800-161 ว่าด้วย supply chain risk และ supplier security clauses ของ ISO 27001 (A.15 ใน mapping ฉบับ 2022) ต่างผลักไปทาง vendor assurance ที่ได้สัดส่วนและอิง evidence แทน questionnaire แบบกวาดทั้งร้าน แนวปฏิบัติ outsourcing ของธนาคารแห่งประเทศไทยก็ใช้ตรรกะเดียวกันนี้กับสถาบันการเงินและ vendor วิกฤตของพวกเขา

ต่อเนื่อง ไม่ใช่ครั้งเดียวจบ #

ความเสี่ยง vendor ไม่เคยหยุดนิ่ง vendor ที่ผ่าน review เมื่อปีก่อนอาจถูก acquisition ถูกเจาะ หรือเปลี่ยน sub-processor เงียบ ๆ ในปีนี้ก็ได้ โมเดลที่ก้าวสู่ความเป็นผู้ใหญ่จะ revalidate ตามรอบที่อิงความเสี่ยง monitor หา signal (data breach, การเปลี่ยนเจ้าของ, certificate หมดอายุ) และมี offboarding path ที่ revoke สิทธิ์เข้าถึงได้จริง ไม่ใช่แค่ยกเลิก invoice

บริการ Third-Party Risk Management ของเราสร้าง tiering model ให้องค์กร ลงมือ review เชิงลึก และร่าง security schedule ในสัญญาที่ทีม legal ของคุณต้องใช้ จับคู่กับ Regulatory Compliance เพื่อ map ข้อผูกพันด้าน vendor เข้ากับข้อกำหนด BOT และ ISO 27001