มิติ 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 อิสระมาตรวจปีละครั้ง แล้วลูกค้าทุกรายใช้ report ฉบับเดียวกันร่วมกัน

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

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

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

• ใช้เมื่อ vendor ทำ payroll, billing, ระบบบัญชี ที่ data ไหลเข้า financial statement ของลูกค้า
• audit ตามมาตรฐาน SSAE 18 (Statement on Standards for Attestation Engagements) ในฝั่ง US ที่ออกโดย AICPA หรือ ISAE 3402 (International Standard on Assurance Engagements) ในระดับ international ที่ออกโดย IAASB (International Auditing and Assurance Standards Board)

ISAE 3402 vs SOC 1 ต่างกันยังไง? — เนื้อหา + objective เหมือนกัน คือ Assurance Reports on Controls at a Service Organization ต่างที่ เขตอำนาจ ครับ ลูกค้าใน US บังคับ SSAE 18 / SOC 1 ส่วนลูกค้าใน Europe + Asia + commonwealth ส่วนใหญ่รับ ISAE 3402 ได้ vendor ระดับ global บางเจ้าออกทั้ง 2 report พร้อมกัน (เพราะลูกค้าอยู่หลายเขต) แต่ในมุม auditor — report ทั้ง 2 ตัวให้ assurance ระดับเดียวกัน อ่าน opinion + scope + exception เหมือนกันได้เลย

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 ครับ