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

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

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

นั่นคือสิ่งที่ 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 ได้

Performance Management + Training#

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

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

HR Controls — 8 องค์ประกอบที่ Auditor ดู#

CRM Section 2.8.4 list HR sub-elements ที่ครอบคลุมทั้ง lifecycle ของพนักงาน auditor ต้องตรวจครบ ไม่ใช่แค่ recruiting + termination:

1. Recruiting and Hiring

• Background check, reference check, NDA, policy acceptance
• (เราคุยใน “Hiring Controls” ข้างต้น)

2. Employee Handbook

• Document ที่ระบุ rights + responsibilities ของพนักงาน
• ครอบ acceptable use, code of conduct, security expectations
• พนักงานต้อง acknowledge receipt เป็นเอกสาร

3. Training

• Initial training (onboarding) + ongoing training (annual)
• Records ตามที่คุยข้างบน

4. Scheduling and Time Reporting

• ระบบบันทึกเวลาทำงาน + overtime + leave
• เป็น input ของ payroll + audit trail สำหรับ access patterns
• ในมุม IT: time reporting system = financial impact + privacy implication (employee monitoring)

5. Terms and Conditions of Employment

• Contract ที่ระบุ scope of work, confidentiality, IP ownership, post-employment restrictions
• ใน IT context: developer ที่เขียน code ขณะทำงาน = IP ของบริษัทหรือของตัวเอง?

6. Expectations During Employment

• Performance standards
• Code of conduct — รวม security policies, acceptable use
• พนักงานต้องเซ็นยอมรับ — เพื่อให้ enforceable

7. Employee Performance Management

• Periodic performance review (annual / quarterly)
• KPIs ที่ measurable + tied กับ business outcomes
• Documentation สำหรับ promotion / termination decisions

8. Disciplinary Actions

• Process สำหรับ violations (security policy, code of conduct, performance)
• ขั้นตอนต้อง consistent — ไม่ใช่ subjective
• Documentation บังคับสำหรับ legal protection

9. Promotion Policies

• Criteria สำหรับ promotion ที่ documented + objective
• Auditor มองหาว่า promotion ในตำแหน่ง sensitive (DBA, finance) ผ่าน formal review มั้ย หรือเป็นแค่ “นาย sponsor”

10. Required Vacations (= Mandatory Leave)

• ที่เราคุยข้างต้น — fraud detection control

11. Retention and Succession Plans

• Plan ที่ระบุ key roles + successors
• ป้องกัน single point of failure (พนักงาน critical คนเดียว — ลาออก = บริษัทพัง)
• IT context: DBA คนเดียวที่รู้ database schema = succession plan ที่ขาด

12. Termination Policies

• ที่เราคุยข้างต้น — revoke access ทันที

ที่ exam ออกบ่อย: บริษัทที่มี HR program “ครบ” ตาม checklist 12 ข้อ แต่ขาด disciplinary consistency หรือ retention/succession → HR governance gap ที่ auditor flag

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 บัญชีดูต่อ

Software Expenses vs Capitalization — Specific Rules#

CRM Section 2.8.6 ระบุ specific rules สำหรับ software ที่ต้องเข้าใจ:

ที่ Capitalize (= asset):

• Software ที่ purchased + ใช้ระยะยาว (>1 ปี) — ค่า license + initial installation
• Internal software development costs หลัง เข้าสู่ application development phase (coding + testing)
• Major upgrades ที่ extend useful life

ที่ Expense (= immediate cost):

• Subscription / SaaS — รายเดือน / รายปี (ใช้แล้วหมด)
• Maintenance + minor patches
• Internal development costs ก่อน application development phase (research, requirements gathering)
• Training + data conversion

Trap: ภายใต้ IAS 38 (Intangible Assets standard) บางประเภทของ software development cost ต้อง capitalize ไม่ใช่ choice auditor flag ถ้าบริษัท expense ทั้งหมดเพื่อ tax benefit

Case study คลาสสิคของวงการ: บริษัทที่ทำ digital transformation 100M baht — ถ้า expense ทั้งหมดในปีเดียว = financial year ขาดทุน + book value ของ asset undercount มหาศาล → financial statement misleading

IS auditor หา pattern แบบนี้: ค่าใช้จ่าย IT major (>10M) ที่ถูก expense ในปีเดียว → flag ให้ accounting auditor verify ตาม IAS 38

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 จริงๆ