มิติ 1: ใครเป็นคนทำ?#

• Insourced — ใช้พนักงานบริษัทเอง
• Outsourced — ใช้ vendor ภายนอก
• Hybrid — ผสมผสาน

มิติ 2: ทำงานที่ไหน?#

• Onshore / Onsite — ในประเทศเดียวกัน หรือในออฟฟิศบริษัท
• Nearshore — ประเทศใกล้เคียง (เช่น ไทย → ลาว, มาเลเซีย)
• Offshore — ประเทศไกล (ไทย → ฟิลิปปินส์, อินเดีย, ยุโรปตะวันออก)

Combination = ความเสี่ยงต่างกัน#

ตัวอย่าง:

• Insourced + Onsite = ความเสี่ยงต่ำสุด (controllable ที่สุด แพงที่สุด)
• Outsourced + Offshore = ความเสี่ยงสูงสุด (cost-effective แต่มีความเสี่ยงเรื่อง regulatory + cultural + time zone + cross-border data transfer)

แต่ละ combination ต้องการ governance ที่เหมาะสม ไม่มี “best model” สำหรับทุกบริษัทหรอกครับ

กระบวนการที่ดีก่อนเลือก Vendor#

1. Requirements — เขียนชัดว่าต้องการอะไร (functional + security + compliance)
2. RFP (Request for Proposal) — ส่งให้ vendor หลายเจ้าเสนอ
3. Evaluation — ประเมินตาม criteria ที่กำหนดไว้ก่อน (ไม่ใช่หลัง vendor เสนอแล้วเปลี่ยน criteria)
4. Due diligence — เจาะลึกลงไป
5. Negotiation — ต่อรองรายละเอียด
6. Contract — เซ็น

Due Diligence ครอบคลุมอะไร?#

• Financial viability — vendor มี cash flow แข็งแรง? เสี่ยงล้มภายใน 5 ปีของสัญญามั้ย
• Technical capability — เคยทำ project ขนาดเดียวกันมาก่อน? Track record
• Security posture — มี security certification (ISO 27001, SOC 2)? Pen test ครั้งล่าสุดเมื่อไหร่
• Compliance history — เคยถูก fine จาก regulator มั้ย เคยมี data breach มั้ย
• References — ลูกค้าเดิมคิดยังไง
• Insurance — มี cyber insurance + professional liability ที่ครอบคลุม

Trap: บริษัทที่เลือก vendor จากราคาอย่างเดียว (lowest bid) → ได้ vendor ที่ตัด corner ในเรื่อง security เพื่อให้ราคาต่ำ

หมวดที่ 1: Service Quality#

• SLA (Service Level Agreement) — uptime, response time, throughput
• Performance metrics — KPI ที่ measurable
• Variance reporting — ถ้า miss SLA ต้อง report ยังไง
• Penalty clauses — ถ้า miss SLA, vendor ต้อง credit อะไร

หมวดที่ 2: Security + Access#

• Information Security Policy (ISP) ของบริษัทใช้กับ vendor มั้ย vendor ต้อง comply ISP เรา ไม่ใช่ ISP ของ vendor
• Background check ของพนักงาน vendor ที่เข้าระบบเรา
• Access provisioning + deprovisioning process
• Data encryption requirements — at-rest + in-transit
• Incident notification timeline — vendor เจอ breach ต้องบอกเราภายในกี่ชั่วโมง

หมวดที่ 3: Right-to-Audit ⭐#

clause นี้ออกข้อสอบหนักครับ:

Right-to-Audit clause = สิทธิ์ของบริษัทในการเข้าไปตรวจ vendor — เอกสาร ระบบ processes

ถ้าสัญญา ไม่มี right-to-audit clause → IS auditor ไม่มีพื้นฐานทางกฎหมายในการตรวจ vendor → governance gap ใหญ่เลย

หลายสัญญาในไทยไม่มี clause นี้ เพราะ vendor ปฏิเสธ แต่นั่นแปลว่าบริษัท ไม่มีทางตรวจ control ของ vendor ได้

วิธีจัดการถ้า vendor ไม่ยอม:

• เจรจาให้มี right-to-audit ผ่าน third party แทน (เช่น auditor ภายนอกที่ vendor + customer ตกลงใช้)
• หรือยอมรับ SOC report เป็น compensating mechanism (เดี๋ยวลงเรื่อง SOC ต่อ)

หมวดที่ 4: Business Continuity#

• vendor ต้องมี BCP/DRP ที่ test แล้ว
• RTO/RPO ที่ vendor ยอมรับ
• Disaster scenarios ที่ vendor ต้องครอบคลุม

หมวดที่ 5: Data Ownership + Privacy#

• Data ownership — data ของลูกค้าเป็นของบริษัท ไม่ใช่ vendor
• Privacy clauses — ตามกฎหมาย data privacy ที่ใช้บังคับ (PDPA, GDPR)
• Cross-border transfer — ถ้า vendor offshore data ไหลข้ามประเทศ ต้องมี mechanism legal
• Data destruction เมื่อสัญญาจบ — ต้องมี certificate of destruction

หมวดที่ 6: IP + Subcontractor#

• IP ownership — code/document ที่ vendor สร้างให้บริษัทเป็นของใคร
• Subcontractor controls — vendor ใช้ sub-vendor ได้มั้ย ภายใต้เงื่อนไขอะไร
• Restrictions on use — vendor ใช้ data ของบริษัทเพื่อ purpose อื่นได้มั้ย (โดยเฉพาะ AI training data ในยุคนี้)

หมวดที่ 7: Exit Terms#

หลายบริษัทเซ็นสัญญาโดยไม่คิดเรื่อง “ถ้าวันหนึ่งจะออกจาก vendor นี้ล่ะ”:

• Transition assistance — vendor ต้องช่วย migrate ออกได้
• Data return / portability — ได้ data คืนในรูปที่ใช้ต่อได้
• Knowledge transfer
• Time period หลังจากบอกเลิก vendor ยังต้องบริการต่อกี่เดือน

ถ้าไม่มี exit terms ในสัญญา → vendor lock-in สมบูรณ์ → เปลี่ยน vendor ต้องเริ่มใหม่ทั้งหมด

ปัญหาที่ SOC Report มาแก้#

IS auditor ตรวจ vendor ทุกเจ้าด้วยตัวเองไม่ไหวครับ vendor มีหลายเจ้า แต่ละเจ้ามีลูกค้าหลายราย ถ้าทุกลูกค้าส่ง auditor มาตรวจ vendor → vendor ก็ทำงานไม่ได้พอดี

→ เลยมีระบบ third-party audit report ที่ vendor จ้าง auditor (อิสระ) มาตรวจปีละครั้ง แล้วลูกค้าทุกคน share report ฉบับเดียวกัน

นั่นคือ SOC reports — Service Organization Controls

3 ประเภทของ SOC Report#

SOC 1 — controls ที่กระทบ financial reporting ของลูกค้า

• ใช้เมื่อ vendor ทำ payroll, billing, ระบบบัญชี ที่ data ไหลเข้า financial statement ของลูกค้า
• audit ตามมาตรฐาน SSAE 18 (US) หรือ ISAE 3402 (international)

SOC 2 — controls เรื่อง security, availability, processing integrity, confidentiality, privacy (Trust Services Criteria)

• ใช้เมื่อ vendor host ระบบหรือ data ของลูกค้า
• ในยุคนี้ SOC 2 คือ standard de facto สำหรับ cloud + SaaS vendor เลยครับ

SOC 3 — version ที่ publicly shareable ของ SOC 2

• สั้นกว่า ไม่มี detail ของ control testing
• vendor มัก post บนเว็บได้เลย

Type 1 vs Type 2#

ทั้ง SOC 1 และ SOC 2 มี 2 type:

• Type 1 — รายงานว่า “ณ จุดเวลาหนึ่ง vendor มี control ที่ออกแบบเหมาะสม” (point-in-time)
• Type 2 — รายงานว่า “ในช่วงเวลา 6-12 เดือน vendor มี control ที่ทำงาน effectively” (over a period)

Type 2 มีค่ามากกว่า เพราะ test ทำงาน effectively ตลอดเวลา

Trap ที่ออกข้อสอบ#

ใช้ SOC Report ยังไง?#

IS auditor ที่ดี:

1. ขอ report ล่าสุด — ตรวจ period coverage ว่าครอบคลุมหรือไม่
2. อ่าน opinion — qualified, unqualified, adverse
3. อ่าน exceptions / findings — สำคัญกว่า opinion มาก
4. อ่าน management’s response — vendor remediate มั้ย
5. complementary user entity controls — control ที่ vendor ระบุว่า “ลูกค้าต้องทำเอง” — บริษัทเรา implement หรือยัง

Shared Responsibility Model — แย้มก่อนถึง Domain 5#

ใน cloud ความรับผิดชอบของ security แบ่งระหว่าง provider กับ customer ต่างกันตาม service model:

• IaaS (Infrastructure-as-a-Service) — provider ดู hardware + virtualization, customer ดู OS + application + data
• PaaS (Platform-as-a-Service) — provider ดูเพิ่มถึง OS + runtime, customer ดู application + data
• SaaS (Software-as-a-Service) — provider ดูเกือบหมด, customer ดู data + user access

เดี๋ยว Domain 5 จะลงรายละเอียด Shared Responsibility — ตอนนี้รู้ว่า “บางอย่างไม่ใช่ provider’s responsibility” ก็พอครับ

Concentration Risk — ความเสี่ยงที่ใหม่มาก#

ถ้าทุกระบบของบริษัทอยู่บน cloud provider เดียว provider ล่ม = บริษัทล่ม

ตัวอย่างจริง AWS outage ในบาง region ทำให้บริษัทใหญ่ทั่วโลกหยุดทำงานเป็นชั่วโมง เพราะ depend on AWS

Mitigation:

• Multi-cloud strategy (ใช้ provider 2 เจ้าขึ้นไป) — complex และแพง
• Multi-region ภายใน provider เดียว — ระดับกลาง
• DR plan ที่รวม cloud failure scenario — ขั้นต่ำสุด

IS auditor ดูว่า cloud concentration risk ถูก document + accepted by management หรือไม่

Data Residency#

บางกฎหมาย (PDPA, GDPR + กฎเฉพาะวงการ) บอกว่า data ต้องอยู่ในบางประเทศ cloud provider ต้อง offer region ที่อยู่ในประเทศที่กฎหมายกำหนด

Trap: บริษัทที่ migrate ไป cloud โดยไม่เช็ค data residency → data ของลูกค้าไทยอาจไหลไป US server โดยไม่รู้ตัวเลย → PDPA violation

Pattern คลาสสิคของวงการ#

ผู้บริหารบางคนคิดว่า “เซ็น contract = จบ” ความจริง การ govern vendor เพิ่งเริ่ม ที่ตรงนั้น

Ongoing Vendor Monitoring#

หลังเซ็น contract ต้อง:

• Quarterly performance review — ดู SLA, KPI, incident
• Annual security review — ขอ SOC report ใหม่, vulnerability scan ผลล่าสุด
• Regular communication — meeting ทุกเดือน
• Incident review — ทุก incident ของ vendor ที่กระทบบริษัท
• Contract review — ทุกปี ดูว่า contract ยังตรงกับความเป็นจริงมั้ย
• Concentration + dependency review — ถ้า vendor นี้ล่มผลกระทบเป็นไง

QA in Outsourcing — เรื่องที่หลายบริษัทละเลย#

CRM ระบุ Quality Assurance ของ vendor service เป็น dedicated topic ไม่ใช่แค่ SLA tracking

Activities ที่ QA ของ outsourcing ครอบคลุม:

• Periodic vendor audit ตาม right-to-audit clause
• Service quality review ตาม customer feedback + incident data
• Process compliance check — vendor ทำตาม ISP ของบริษัทมั้ย
• Continuous improvement plan — vendor commit ปรับปรุงต่อเนื่องมั้ย

ที่หลายบริษัทพลาดคือ เช็ค SLA ทุกเดือน แต่ไม่เคยทำ QA review ลึก → เจอปัญหา quality drift ที่ไม่สะท้อนใน SLA metric

Service Improvement + User Satisfaction#

CRM ระบุ vendor management ที่ดีต้องครอบคลุม service improvement เป็น ongoing ไม่ใช่ใช้สัญญาเดิมไป 5 ปี:

• User satisfaction surveys เป็นระยะ — feedback จาก end users ที่ใช้ vendor service
• Service improvement plan — vendor ต้องแสดง plan ปรับปรุง service ตาม feedback
• Innovation collaboration — vendor + customer ร่วมกันหาวิธีปรับปรุง
• Annual service review — meeting ระดับ executive ดู outcome + plan ปีหน้า

Trap: บริษัทที่ “renew contract อัตโนมัติทุกปี” โดยไม่ทำ service review → vendor ไม่มี incentive ปรับปรุง → service quality drift

Trap: SLA “Met” ≠ Service “Good”#

vendor อาจ meet SLA ตาม metric ที่ตกลง แต่ service จริงแย่ลงครับ เพราะ SLA ไม่ครอบคลุม dimension สำคัญที่ลูกค้าจริงๆ care

ตัวอย่าง SLA บอกว่า ticket ต้อง response ภายใน 4 ชั่วโมง vendor response ภายใน 3:59 ทุกครั้ง แต่ response คือ “received, escalating” โดยไม่ได้ทำอะไรจริง → SLA met แต่ business value ไม่ได้

→ SLA ที่ดีต้องวัด outcome ไม่ใช่แค่ activity ครับ