ปัญหาที่เจอบ่อย#

CIO ของบริษัทขนาดกลางที่ผมรู้จักเล่าให้ฟังครั้งหนึ่ง: ปีหนึ่งเขามี 47 IT project รออนุมัติ — ทุก project มีเหตุผล ทุก department ขอ ทุก vendor มาเสนอ

ถ้าตัดสินใจ project ต่อ project แบบ “ใครเข้ามาขอก่อนได้ก่อน” หรือ “ใครเสียงดังที่สุดได้” — ภาพรวม IT investment ของบริษัทจะออกมาเป็นเหมือน ครัวที่มีหม้อหุงข้าว 3 ใบ แต่ไม่มีเตาแก๊ส

นั่นคือสิ่งที่ Portfolio Management มาแก้

Portfolio Management vs Project Management#

Project Management = บริหารแต่ละ project ให้ออกตามเวลา + งบ + scope (เดี๋ยว Domain 3 จะคุยเรื่องนี้)

Portfolio Management = ตัดสินใจ ระดับองค์กร ว่า project ไหนทำ project ไหนไม่ทำ — ดูภาพรวม

ดูจาก 3 มิติ:

1. Strategic Alignment — project นี้ support business strategy ที่ board approve มั้ย
2. Value — คาดว่าจะได้คืนคุ้มค่ามั้ย
3. Risk — ความเสี่ยงของ project นี้ + ผลที่ failure จะมีต่อบริษัท

Trap: บริษัทที่อนุมัติทุก project ตามคำขอ ไม่มี portfolio view → IT landscape กระจัดกระจาย, ค่าใช้จ่ายซ้ำซ้อน, integration เป็นปัญหาตลอด

IS auditor มองหา: portfolio criteria ที่เป็นทางการ + ใช้ consistently + linked กับ strategy

Hiring Controls#

ก่อนพนักงานใหม่เริ่มงาน:

• Background check — ประวัติอาชญากรรม, อ้างอิงงานเดิม, การศึกษา
• Reference check — โทรเช็คกับนายเก่า
• NDA / Confidentiality agreement — ลงนามก่อนเริ่มงาน
• Acceptance of policies — รับทราบ + ลงนาม Information Security Policy + Acceptable Use Policy

Trap: บริษัทที่ “เร่งจ้าง” และให้พนักงานเริ่มก่อนเช็คประวัติ → ถ้ามีประวัติแย่ก็เกินไปแล้ว ที่จะ revoke access แบบไม่กระเทือนงานที่ทำไปแล้ว

Termination Procedure#

วันที่พนักงานออก:

• Revoke access ทันที — ไม่ใช่ “พรุ่งนี้ค่อยทำ” — window ที่ขาด revocation = window ที่ risk เปิด
• คืน device + token + access card
• ลบ access ใน cloud + SaaS ทุก system
• Remove จาก distribution list + shared folder
• Exit interview — เรียนรู้ว่าทำไมถึงออก, มีเรื่องน่ากังวลที่ต้อง follow up มั้ย

Trap คลาสสิก: บริษัทที่ revoke access “ภายใน 1-2 วัน” — auditor flag ทันที พนักงานที่ลาออกในวันศุกร์เย็น แล้ว IT ทำ revoke จันทร์เช้า = สุดสัปดาห์ access ยังเปิดอยู่ทั้งหมด

ในกรณีพนักงานถูกไล่ออก (fired) — revoke ต้องเกิด ก่อน บอกเขา ไม่ใช่หลัง เพราะถ้าบอกแล้ว revoke ทีหลัง พนักงานอาจกลับไปลบ data หรือ steal data

Performance Management + Training#

• Performance review ประจำปี — มี KPI ที่ measurable
• Training plan ตาม role — ไม่ใช่ “อยากเรียนอะไรก็ลงทะเบียน”
• Records ของ training — ต้องเก็บหลักฐาน (attendance, certificate)

Trap: บริษัทที่จัดอบรม security awareness ทุกปี แต่ไม่เก็บหลักฐาน — ตอน audit ตอบไม่ได้ว่า “พนักงานคนนี้ได้รับการอบรมจริงมั้ย” → control ที่ไม่มีหลักฐาน = control ที่ไม่มี

Mandatory Leave (บังคับลา)#

หลายบริษัทมีนโยบายว่าพนักงานในตำแหน่งที่ sensitive (DBA, finance, treasury) ต้องลาติดต่อกัน 1-2 สัปดาห์ต่อปี

มันไม่ใช่ “สวัสดิการ” — มันคือ fraud detection control

หลักการ: ถ้าพนักงานทำทุจริต พวกเขาต้องอยู่ทุกวันเพื่อปิดบัง — ถ้าบังคับลา + ใครอื่นเข้ามาทำแทน → ความผิดปกติจะถูกค้นพบ

Trap: บริษัทที่พูดว่า “พนักงานคนนี้ไม่เคยลา 5 ปีเพราะทุ่มเทมาก” — auditor มองเป็น red flag ไม่ใช่ดี

Job Rotation (หมุนเวียนหน้าที่)#

หมุนเวียนพนักงานระหว่าง role/team ทุก 1-3 ปี — ผลพลอยได้:

1. Cross-training — มีคนหลายคนทำงานนั้นเป็น (continuity)
2. Fraud detection — เหมือน mandatory leave — ใครทุจริตในงานเก่าจะถูกเปิดเผยเมื่อคนใหม่มาแทน
3. Career development — พนักงานพัฒนาทักษะหลากหลาย

Trap: Cross-training ที่ทำมากเกินไปจน 1 คนรู้ครบทุก phase ของกระบวนการ critical → SoD violation

ตัวอย่าง: ในระบบ payroll การ cross-train ผู้จัดการคนหนึ่งให้สามารถ enter ข้อมูลพนักงาน + อนุมัติเงินเดือน + ดู report = SoD violation 3 หน้าที่ในคนเดียว

→ Cross-training ดี แต่ต้องไม่ทำลาย SoD — ต้องแบ่งระหว่าง role/responsibility ที่ acceptable

ทำไมต้องมี Change Management?#

ระบบ IT ของบริษัทใหญ่เปลี่ยนแปลงทุกวัน — patch, upgrade, configuration change, deploy code ใหม่

ถ้าไม่มี process — change ไม่ได้ test, ไม่ approved, ไม่ communicate → ระบบล่ม + ไม่มีใครรู้ว่าเปลี่ยนอะไร

องค์ประกอบของ Change Management ที่ดี#

1. Request — ใครจะเปลี่ยนต้อง submit formal request
2. Impact assessment — เปลี่ยนแล้วกระทบใคร, system ไหน
3. Approval — Change Advisory Board (CAB) approve (ขึ้นกับ severity)
4. Test ใน non-production — ทดสอบก่อน deploy
5. Schedule — เลือกเวลา deploy ที่กระทบน้อย (off-peak)
6. Communication — แจ้ง stakeholder ก่อน
7. Deploy — ตามแผน
8. Verify — confirm ว่าเปลี่ยนสำเร็จ
9. Rollback plan — ถ้าพังต้องกลับได้

เดี๋ยว Domain 4 จะลงรายละเอียด change management ในระดับ operational + emergency change handling — ตอนนี้รู้ภาพรวมพอ

Trap: Emergency Change#

บริษัทมักมี “emergency change” ที่ skip บางขั้นตอนเพื่อความเร่งด่วน

ผิดที่: skip ไม่ได้ — แค่ shorten + document หลังจากนั้น emergency change ที่ไม่ document = unauthorized change ที่ไม่มีใครรับผิดชอบ

Cost Allocation / Chargeback#

ในบริษัทใหญ่ IT ให้บริการกับหลาย business unit — ใครจ่ายค่า IT?

3 model หลัก:

1. Allocated — แบ่งให้แต่ละแผนกตามสัดส่วน (เช่น headcount, revenue) — ง่าย แต่ไม่สะท้อนการใช้จริง
2. Chargeback — แต่ละแผนกจ่ายตามที่ใช้จริง (เช่น GB ของ storage, CPU hours) — สะท้อนความเป็นจริง แต่ implement ยาก
3. Showback — แสดงให้เห็นว่าแต่ละแผนกใช้เท่าไหร่ แต่ไม่ charge — กลางๆ

Trap: บริษัทที่ allocate IT cost เท่ากันทุกแผนก → แผนกที่ใช้น้อยจ่ายเกินจริง, แผนกที่ใช้มาก subsidized → incentive ผิด

Capex vs Opex#

นี่คือเรื่องที่ IS auditor ต้องเข้าใจระดับหนึ่ง — ไม่ใช่ในฐานะ accountant แต่เพื่อ flag pattern ที่ผิด:

• Capital Expenditure (Capex) — ลงทุนใน asset ที่อายุยาว (เช่น data center hardware, software ที่ใช้ระยะยาว) → capitalize + depreciate
• Operating Expenditure (Opex) — ค่าใช้จ่ายประจำ (เช่น cloud subscription, license ปีต่อปี) → expense ในปีที่เกิด

ภายใต้ IAS 38 (intangible asset accounting) — ค่า software development บางประเภทต้อง capitalize

Trap: บริษัทที่ expense ทุก IT cost เพื่อความง่าย — overstate expense + understate asset → financial misstatement

IS auditor ไม่ใช่ accountant — แต่เห็น pattern ที่ผิดต้อง flag ให้ auditor บัญชีดูต่อ

RPO + RTO — แย้มก่อนถึง Domain 4#

CRM แย้ม 2 metric สำคัญที่ผู้บริหารต้องเข้าใจ:

• RPO (Recovery Point Objective) — ยอมรับการสูญเสีย data ได้กี่ชั่วโมง (ถ้าระบบล่มเวลา 14:00 และ backup ล่าสุด 10:00 → สูญ 4 ชั่วโมง)
• RTO (Recovery Time Objective) — ระบบต้องกลับมาทำงานได้ภายในกี่ชั่วโมง

Domain 4 จะลงรายละเอียด BIA, BCP, DRP ที่ใช้ 2 metric นี้ — ตอนนี้รู้แค่ว่ามันเป็น input ของ business continuity planning ก็พอ ผู้บริหารที่ไม่รู้จัก 2 metric นี้ = ยังไม่ได้ตัดสินใจ business continuity risk จริง ๆ