Phase 1 — Feasibility Study#

ตอน 24 คุยไปแล้ว ตอบคำถาม “ระบบนี้ควรสร้างไหม” + “build vs buy”

เนื้อหาส่วนนี้ทับกับ Section 3.2 มาก ผมเลือกใช้ตอน 24 เป็น primary treatment ไม่อธิบายซ้ำ

Phase 2 — Requirements Definition#

ระบบจะทำอะไรได้บ้าง ละเอียดระดับที่ developer/vendor เอาไปสร้างได้

Requirements ที่ดีต้องมีคุณสมบัติ:

• Testable — เขียนในรูปที่ทดสอบได้ ไม่ใช่ “ระบบต้องเร็ว” แต่เป็น “ระบบต้องตอบสนอง 95% ของ transaction ภายใน 2 วินาที”
• Traceable — ทุก requirement ต้อง trace กลับไป business need ใน business case ได้ (requirement traceability matrix)
• Complete — ครอบคลุม functional + non-functional (security, performance, usability, compliance) + control requirements

มุม IS auditor: ขอดู requirement traceability matrix ถ้าไม่มี = red flag ทันที เพราะแปลว่าอาจมี requirement ที่ใส่เข้ามาภายหลังโดยไม่มี business justification หรือมี business need ที่หายไประหว่างทาง

Phase 3a — Software Selection & Acquisition (ถ้าเลือก buy)#

ถ้า feasibility study ตอบว่า “ซื้อ” แทนที่จะ “สร้าง” เข้าสู่กระบวนการ acquisition ที่จะคุยลึกข้างล่างนี้

Phase 3b — Design#

ถ้าเลือก build เอง ออกแบบระบบในระดับ technical

Design phase เกิด artifact หลายอย่าง:

• ERD (Entity Relationship Diagram) — โครงสร้างข้อมูล
• DFD (Data Flow Diagram) — การไหลของข้อมูลในระบบ
• System architecture — components ของระบบและ interface ระหว่างกัน
• Software baseline — version ของ design ที่ approved แล้ว
• Design freeze — จุดที่ design ถูก lock ทุกการเปลี่ยนแปลงหลังจุดนี้ต้องผ่าน change control

กับดัก: organization ที่ “ขอเปลี่ยน requirement” หลัง design freeze โดยไม่ผ่าน change control = control gap ใหญ่ developer มักยอมแก้ “เพราะแก้นิดเดียว” ไม่ใช่หน้าที่ของ developer ที่จะตัดสินอยู่แล้ว

Phase 4a — Configuration (ถ้าซื้อระบบสำเร็จรูป)#

ระบบ COTS / ERP ที่ซื้อมาต้อง configure ให้เข้ากับ process ของบริษัท ตั้งค่า workflow, master data, role permissions, reports

กับดัก: การ configure ไม่ใช่หน้าที่ของ vendor เพียงฝ่ายเดียว buyer ต้องอนุมัติ configuration ก่อน production และ configuration changes ทั้งหมดต้องผ่าน change control เหมือน custom code

Phase 4b — Development (ถ้า build เอง)#

เขียนโค้ดตาม design ใช้ programming standard, peer review, IDE, debugger

ขั้นตอนระดับโค้ดที่ auditor ต้องตรวจ:

• Coding standard ถูก enforce ผ่าน automated tool หรือ peer review
• Source code repository มี version control ครบและไม่อนุญาตให้ commit ตรงไปยัง production branch
• Code review ก่อน merge ป้องกัน developer commit ไปแล้วไม่มีใครเห็น

Phase 5/6 — Testing + Implementation#

ทดสอบว่าระบบทำงานถูกตามที่ design ก่อน go-live เรื่องนี้ลึกพอที่จะเป็นบทแยกใน ตอน 28

ในบทนี้รู้แค่ว่า ก่อน go-live ต้องผ่าน UAT ที่ทำโดย end users (ไม่ใช่ vendor และไม่ใช่ IT) และต้องมี certification + accreditation อย่างเป็นทางการ

ฝั่ง Build (สร้างเอง)#

ข้อดี

• ระบบตรงกับ process ของบริษัท 100%
• ควบคุม source code, IP, roadmap ได้เอง
• เปลี่ยนแปลงในอนาคตทำได้ตามต้องการ

ข้อเสีย

• เวลาและต้นทุนสูง
• ต้องมีทีม dev ที่มีความสามารถจริง
• ต้องบำรุงรักษาเอง
• Time-to-market ช้า

ฝั่ง Buy (ซื้อสำเร็จรูป / COTS)#

ข้อดี

• เร็วกว่า — vendor มี product ที่ใช้กับลูกค้าหลายเจ้าแล้ว
• ราคาต่อ feature ถูกกว่า เพราะ vendor amortize cost
• Best practice ฝังใน process ของระบบ
• Vendor รับผิดชอบ patching, security update

ข้อเสีย

• Process ของบริษัทอาจต้องปรับให้เข้ากับระบบ ไม่ใช่ระบบปรับให้เข้ากับ process
• Customization มี limit
• ขึ้นอยู่กับ vendor — vendor lock-in, vendor financial stability เป็น risk
• Source code ไม่ได้
• Right-to-audit ต้อง negotiate ในสัญญา

มุม IS auditor: การตัดสินใจ build vs buy ต้องอ้าง gap analysis ที่เปรียบเทียบ requirement ของบริษัทกับ feature ของ COTS option ที่พิจารณา ถ้า gap น้อย → buy ทำให้ ROI สูง ถ้า gap ใหญ่ + customization แพง → ใกล้เคียงกับ build อยู่ดี

”Buy” ในปี 2026 ส่วนใหญ่คือ “เช่า cloud” — รู้จัก *aaS Models ก่อนตัดสินใจ#

ก่อนยุค cloud “Buy” หมายถึงซื้อ license + ลง software ใน server ของบริษัท. แต่ในปี 2026 “Buy” เกือบทั้งหมด = เช่า service จาก cloud provider — แตกย่อยเป็นหลาย model ตาม “ใครรับผิดชอบชั้นไหนของ stack”

ลองนึก stack ของระบบเป็น 8 ชั้น (ล่างขึ้นบน): Hardware → Virtualization → OS → Runtime → Scaling → Application Code → Data & Config. ยิ่ง model ขยับไปทาง SaaS ยิ่ง vendor ดูแลชั้นล่างมากขึ้น คุณดูแลแค่ชั้นบน

อ่านเป็นภาพ — ยิ่งลงล่างของตารางยิ่ง “คุณดูแลน้อย” / vendor ดูแลมาก. SaaS = ของพร้อมใช้ เปิดเว็บใช้เลย / IaaS = ยังต้องลง OS + ลง software เอง บน VM ของ cloud

Note: CaaS (Containers as a Service) เป็น layer ระหว่าง IaaS กับ PaaS — vendor ดูแล OS ที่ container รันอยู่ แต่คุณยังต้อง package app + จัดการ container orchestration. โผล่บ่อยใน infrastructure ยุคใหม่ (CSF EP.33 Container + Kubernetes อธิบายลึก)

ทำไม IS auditor ต้องสน *aaS Models ใน Phase 1#

เพราะ “Buy” 1 ตัวเลือก เปลี่ยน trade-off ของ Build vs Buy ทั้งหมด

• เช่น HR system — เลือก SaaS (Workday) = ตัดสินใจ buy เต็ม + ติด vendor lock-in สูงสุด + customization ต่ำสุด + go-live เร็วสุด
• HR system เดียวกัน — เลือก PaaS (build บน AWS) = ผสม build + buy + ควบคุม code ได้ + ดูแล infrastructure เอง
• HR system เดียวกัน — เลือก IaaS (ลง software เอง บน EC2) = build เต็ม + cloud แค่ให้ HW + ความรับผิดชอบเกือบเท่า on-prem

3 ตัวเลือกนี้คือ 3 จุดบน spectrum ไม่ใช่ “buy หรือ build” แต่เป็น “buy ระดับไหน”

Shared Responsibility — กับดักที่ผู้บริหารพลาดบ่อยที่สุด#

ที่บริษัทไทยพลาดบ่อยใน SaaS contract — เข้าใจว่า “vendor ดูแลทุกอย่าง” เพราะเป็น SaaS. ผิด

นี่คือ Shared Responsibility Model ที่ทุก cloud provider ใช้ — vendor ดูแล “security OF the cloud” / ลูกค้าดูแล “security IN the cloud” (data + access + config). หลายเคส breach ใน SaaS — เกิดเพราะลูกค้า config ผิด ไม่ใช่ vendor บกพร่อง

มุม IS auditor: ก่อน sign SaaS/PaaS/IaaS contract — review Shared Responsibility Matrix ของ vendor ทุกครั้ง. คำถามที่ต้องตอบได้ — “data ของบริษัทเรา อยู่ที่ไหน + ใครเข้าได้ + backup ใครรับผิดชอบ + retrieve ออกมาเองได้ไหม”. ถ้า team บอกว่า “vendor ดูแลให้หมด” = สัญญาณว่ายังไม่อ่าน contract ละเอียด

Cross-ref: เรื่อง Shared Responsibility ลึก + เคส cloud breach จริง (Capital One 2019 / S3 bucket misconfigurations) จะอยู่ใน CISA D5 — Cloud + Virtualization และ CSF EP.32 — Cloud Shared Responsibility. ใน D3 รู้แค่ “4 models + Shared Responsibility มีอยู่” พอตัดสินใจ Build vs Buy ได้

ขั้นที่ 1 — เขียน RFP / ITT#

RFP (Request for Proposal) หรือ ITT (Invitation to Tender) = เอกสารที่บริษัทส่งไปยัง vendor หลายราย ระบุ:

• ระบบที่ต้องการ — functional + non-functional requirements
• เกณฑ์การประเมิน — vendor จะถูกวัดด้วยอะไร
• เงื่อนไขสัญญาที่ไม่ negotiate — เช่น right-to-audit, source code escrow, SLA
• Timeline ของ procurement

กับดัก: “เลือก vendor ก่อนแล้วค่อยทำ RFP เพื่อให้กระบวนการดูถูกต้อง” นี่คือสิ่งที่ auditor จะ flag ทันที RFP ต้องส่งให้ vendor หลายราย และ vendor ที่ชนะต้องชนะตามเกณฑ์ที่ตั้งไว้ล่วงหน้า

ขั้นที่ 2 — ประเมิน Vendor#

เกณฑ์การประเมินที่ดี ตั้งไว้ก่อน เปิดซองและมี น้ำหนัก ที่ approve โดย steering committee แล้ว ครอบคลุม:

• Functional fit — ระบบของ vendor ตอบ requirement ได้กี่เปอร์เซ็นต์
• Vendor financial stability — vendor จะอยู่กับเราอีกกี่ปี ดู financial statement, customer references
• Technical compatibility — เข้ากับ infrastructure ปัจจุบันได้ไหม
• Support model — มี support ระดับไหน timezone ไหน SLA แบบใด
• Total cost of ownership — ไม่ใช่แค่ license แต่รวม customization, training, maintenance, integration
• Security posture — vendor มี SOC report ไหม certifications อะไร

กับดัก: vendor ที่ราคาถูกที่สุดไม่ใช่ vendor ที่ดีที่สุด และ vendor ที่ทำ presentation สวยที่สุดก็ไม่ใช่ vendor ที่ดีที่สุด การประเมินต้องตามเกณฑ์ที่ตั้งไว้ก่อน

ขั้นที่ 3 — Proof of Concept (PoC)#

ก่อนเซ็นสัญญา vendor หลักๆ ควรทำ PoC ลองให้ระบบทำ scenario สำคัญในสภาพแวดล้อมที่ใกล้เคียง production ให้ดู

PoC ตรวจ:

• ระบบทำงานได้จริงตามที่ presentation บอกไหม
• Performance พอไหม
• Integration กับระบบเดิมเป็นอย่างไร
• User experience จริง

ขั้นที่ 4 — สัญญา + Right-to-Audit Clause#

สัญญากับ vendor ต้องมี clause สำคัญหลายตัว และนี่คือเรื่องที่ผูกกลับไป ตอน 19 ของ Domain 2 (Vendor Management)

• Right-to-audit — ลูกค้ามีสิทธิ์ตรวจ vendor หรือ require ให้ vendor ส่ง SOC report ที่ระดับเหมาะสม
• SLA (Service Level Agreement) — ระบุ availability, response time, resolution time + ค่าปรับเมื่อไม่ถึง
• Software escrow agreement — ดูหัวข้อแยกข้างล่าง สำคัญพอที่จะคุยเป็นหัวข้อของตัวเอง
• Data ownership — ข้อมูลที่อยู่ในระบบเป็นของลูกค้า ไม่ใช่ vendor
• Exit clause — ขั้นตอนการย้ายออกถ้าจะเลิกสัญญา ต้องส่งคืนข้อมูลในรูปแบบที่ใช้ต่อได้

มุม IS auditor: สัญญาที่ไม่มี right-to-audit = auditor ทำ assurance ไม่ได้ บริษัทที่เซ็นสัญญาแบบนี้กำลังโยน control assurance ออกไปให้ vendor เฉยๆ

ขั้นที่ 4.5 — Software Escrow Agreement (เจาะลึก)#

Software escrow agreement = ข้อตกลง 3 ฝ่าย — buyer + vendor + escrow agent (บุคคลที่สามที่เป็นกลาง เช่น สำนักงานทนายความหรือบริษัทรับฝากที่เชี่ยวชาญด้านนี้) — ที่ vendor นำ source code + build script + deployment doc ไปฝากไว้กับ escrow agent ตามรอบที่ตกลง (เช่น ทุกครั้งที่ปล่อย release ใหม่)

ลองนึกถึงร้านอาหาร franchise ครับ — chef ของ headquarter เป็นคนคิด recipe แต่ recipe ฉบับจริงถูกเก็บไว้ในตู้เซฟของทนายคนที่สาม. ถ้า headquarter เจ๊ง — สาขาเปิดตู้เซฟเอา recipe มาทำต่อได้ ไม่ต้องปิดร้าน

Trigger condition ที่ escrow agent จะปล่อย source code ให้ buyer ระบุในสัญญา — ปกติคือ:

• Vendor bankrupt / เลิกกิจการ
• Vendor หยุด support product ที่ buyer ใช้อยู่
• Vendor ไม่ทำตาม SLA ใน support เป็นเวลานานเกินที่ตกลง
• Vendor ถูก acquired แล้ว product ถูก discontinued

ทำไม IS auditor สนใจ: Software escrow คือ mitigation control ของ vendor-viability risk สำหรับระบบ critical ที่บริษัทพึ่งพา vendor 100% ในการ maintain ระบบ critical ที่เป็น vendor-developed software โดยไม่มี escrow = บริษัทกำลังพนันความต่อเนื่องของธุรกิจกับสุขภาพการเงินของ vendor

กับดัก ⚠️: เซ็น escrow agreement แล้วถือว่าจบ

ผิดครับ escrow agreement ต้องระบุชัดว่า:

• Vendor ต้อง update escrow deposit ทุกครั้งที่ปล่อย release ใหม่ (ไม่ใช่ฝากตอน sign สัญญาครั้งเดียว แล้วลืม)
• Escrow agent ต้อง verify ว่าสิ่งที่ฝากใช้งานได้จริง — compile + build ได้ (verification escrow)
• ครอบคลุม build environment + dependency + documentation ไม่ใช่แค่ source code เปล่าๆ ที่เปิดอ่านไม่รู้เรื่อง

ผมเคยได้ยินเคสที่บริษัท trigger escrow แล้วได้ source code มา แต่ compile ไม่ผ่านเพราะไม่มี build script — เท่ากับมี control ที่ไม่ทำงานจริง

ขั้นที่ 4.7 — Conference Room Pilot (ก่อนเซ็นสัญญาจริง)#

Conference room pilot (CRP) = ขั้นตอนที่ vendor setup ระบบของตัวเองใน environment ที่ใกล้เคียง production (มัก demo ที่ห้องประชุมของ vendor หรือ pre-prod environment ของ buyer) แล้วให้ทีม business ของ buyer ลอง รัน workflow จริงของตัวเอง ในระบบนั้น

ต่างจาก vendor presentation ตรงที่ — presentation คือ vendor เล่าให้ฟัง แต่ CRP คือ buyer ลงมือทำเอง ใช้ข้อมูลตัวอย่างที่ใกล้เคียงข้อมูลจริง

ลองนึกถึงการซื้อรถ — vendor presentation = ดู brochure + นั่ง showroom ฟัง sales เล่า. CRP = ขับ test drive ในเส้นทางที่คุณขับจริงทุกวัน (รวมตรอกแคบของบ้านคุณ ทางลาดที่บ้านคุณ)

CRP ตอบคำถามที่ presentation ตอบไม่ได้:

• Workflow ของบริษัทจริงๆ ระบบรองรับได้กี่ % โดยไม่ต้อง customize
• จุดไหนต้อง workaround / customize / แก้ business process ของบริษัทเอง
• User ของบริษัทใช้แล้วรู้สึกอย่างไร — usability จริง ไม่ใช่ usability ที่ sales พูด
• Integration กับระบบเดิมเป็นอย่างไรจริง

ผลของ CRP เอามาประกอบการตัดสินใจขั้นที่ 4 (เซ็นสัญญา) — ถ้า gap ใหญ่กว่าที่ vendor บอก = renegotiate หรือถอย

มุม IS auditor: acquisition ที่ skip CRP แล้วเซ็นสัญญาเลย = high risk ของ “ซื้อมาแล้วใช้ไม่ได้” ที่ค้นพบหลัง go-live. ผมเคยเห็นเคส ERP ที่ผ่าน vendor presentation สวยมาก แต่พอเอามารัน workflow จริงของบริษัทถึงรู้ว่า approval chain 4 ขั้นที่บริษัทใช้ ระบบรองรับได้แค่ 2 ขั้น — ค้นพบหลังเซ็นสัญญาไปแล้ว = ต้อง customize หนักจน TCO เกินงบ 60%

ขั้นที่ 5 — Acceptance Testing#

นี่คือกับดักที่อันตรายที่สุดของกระบวนการ acquisition และเป็นเรื่องที่ทดสอบบ่อยที่สุดในข้อสอบ

กับดัก ⚠️: Vendor ทำ acceptance testing แทน buyer

หลายบริษัทให้ vendor “ทดสอบ” ระบบของตัวเอง แล้วส่ง test report มาให้ buyer อนุมัติ ผิดครับ

เหตุผลคือ vendor มี incentive ให้ test ผ่าน:

• Vendor ได้เงินตอน acceptance
• Vendor รู้จุดอ่อนของระบบดีที่สุด และมีเหตุผลที่จะไม่ทดสอบส่วนที่จะพัง
• Vendor อาจจะเปลี่ยนเวอร์ชันของระบบหลังจากผ่าน test

หลักของ acceptance testing สำหรับ acquired software:

• Buyer ทดสอบเอง ในสภาพแวดล้อมที่ buyer ควบคุม
• ใช้ test cases ที่ buyer เขียน ไม่ใช่ test cases ที่ vendor ส่งมา
• ทดสอบ edge cases + negative scenarios ที่ vendor มัก skip
• Sign-off เป็นทางการก่อนเริ่มใช้งานจริง

นี่คือเหตุผลที่ trap pattern “vendor does the testing for acquired software” ถูกแอบมาใน CISA exam บ่อยมาก คนตอบผิดเพราะคิดว่า “vendor เป็นผู้เชี่ยวชาญน่าจะทดสอบดีกว่า”