EGIT คืออะไร?#

EGIT = Enterprise Governance of Information and Technology — กรอบที่ board และ executive management ใช้ในการทำให้แน่ใจว่า IT ของบริษัท สนับสนุน เป้าหมายธุรกิจ และ ขยาย ความสามารถขององค์กร

จุดที่ผมอยากให้สังเกตในนิยาม: “board และ executive management” — ไม่ใช่ “CIO” ไม่ใช่ “ฝ่าย IT”

นี่คือ trap ใหญ่อันแรก:

EGIT = หน้าที่ของ board ไม่ใช่หน้าที่ของ IT department

ทำไมถึง trap? เพราะคนทั่วไปเห็นคำว่า “IT” แล้วคิดอัตโนมัติว่า “เรื่องของฝ่าย IT” เถ้าแก่หลายคนเซ็นมอบเรื่อง EGIT ให้ CIO ไปจัดการเอง — แล้วก็หายไปไม่มาเช็คอีก

ถ้า board ไม่ engage กับ EGIT จริง ๆ — EGIT ก็เป็นแค่กระดาษที่ CIO เขียนคนเดียวเพื่อเอามาแขวนข้างฝา

ทำไม EGIT ต้องเป็นของ Board?#

ลองคิดดู — IT investment ของบริษัทขนาดกลางอยู่ระดับ 5-15% ของ revenue ทั้งบริษัท เป็นค่าใช้จ่ายที่ใหญ่เป็นอันดับต้น ๆ

ถ้า board ไม่ดู:

• IT investment อาจไม่ตรงกับทิศทางธุรกิจ → ลงทุนใน technology ที่ไม่ generate value
• IT risk (data breach, system failure) อาจไม่ถูก escalate ขึ้น → board รู้ตัวก็ตอนเกิดเหตุ
• ไม่มีคนถามว่า “เงินที่ลงไปคืนมายังไง” — ROI ของ IT หายไปในระบบ

EGIT ที่ดี = board ตอบคำถาม 4 ข้อนี้ได้:

1. Strategic Alignment — IT strategy ของเรา align กับ business strategy ที่ board approve มั้ย
2. Value Delivery — IT investment สร้าง value จริงมั้ย
3. Risk Management — IT risk อยู่ในระดับที่ board ยอมรับมั้ย
4. Resource Management — IT resource (คน เงิน เครื่อง) ถูกใช้คุ้มค่ามั้ย

(สังเกตว่ามันคือ balance ของ benefits, risk, resources — ไม่ใช่แค่ “ระบบ IT ดีหรือไม่ดี”)

นิยามตาม COBIT#

Governance = ประเมินความต้องการของ stakeholder, กำหนดทิศทาง, monitor performance — board เป็นคนทำ

Management = วางแผน, สร้าง, รัน, monitor ตามทิศทางที่ governance วางไว้ — CIO และทีมเป็นคนทำ

ถ้านึกไม่ออก ลองเปรียบเทียบกับโรงเรียนที่ผมเคยใช้ใน ตอน 14:

คำถามที่ทดสอบความเข้าใจ:

• ใครเป็นคนกำหนด risk appetite ของ IT? → Board (governance)
• ใครเป็นคนตัดสินใจซื้อ firewall ยี่ห้อไหน? → CIO (management)
• ใครรับผิดชอบสุดท้ายถ้า data breach? → Board (accountability ที่หาคนแทนไม่ได้)
• ใครต้อง execute incident response? → CISO + ทีม (management)

Trap เสมอ: “EGIT = หน้าที่ของ CIO” — ผิด CIO รัน IT ตามทิศทางที่ board วาง ส่วน EGIT คือกระบวนการที่ board วางทิศทางและตรวจสอบ

3 Lines คืออะไร?#

1
First Line  → operational management ที่ owns risk
2
Second Line → risk + compliance functions ที่ monitor
3
Third Line  → internal audit ที่ provide assurance อย่างอิสระ

แต่ละ Line มีบทบาทต่างกัน — และต้อง ไม่ทำหน้าที่ของกันและกัน

First Line — คนทำงาน + คุม risk ของตัวเอง#

First Line คือ operational management — คนที่ทำงานจริง

เช่น:

• ฝ่ายขายต้อง own risk ของการเก็บข้อมูลลูกค้า
• ฝ่ายผลิตต้อง own risk ของระบบ MES ของตัวเอง
• ฝ่าย IT operation ต้อง own risk ของระบบที่ตัวเอง maintain

First Line ไม่ใช่ “พนักงานระดับล่าง” — แต่หมายถึง “คนที่รับผิดชอบ risk ในงานของตัวเอง” ใครก็ตามที่ทำงานและตัดสินใจประจำวัน อยู่ใน First Line

Second Line — คนกำกับ risk + compliance#

Second Line = ฝ่ายที่ monitor ว่า First Line จัดการ risk ดีมั้ย

เช่น:

• ฝ่าย Risk Management
• ฝ่าย Compliance (ตามกฎหมาย/regulation)
• CISO + ทีม Information Security
• Quality Assurance

Second Line ไม่ใช่คนทำเอง แต่ คอยช่วย + ตรวจ + report ขึ้นไปยังผู้บริหาร

Third Line — Internal Audit (Independent Assurance)#

Third Line = internal audit / IS audit — ทีมที่ provide independent assurance ต่อ board ว่า First Line + Second Line ทำงานจริงมั้ย

ลักษณะสำคัญที่เราเรียนใน D1:

• รายงานตรงต่อ audit committee (ไม่ใช่ CFO ไม่ใช่ CIO)
• มี Audit Charter ที่ board approve
• มี independence ทั้งทาง structural และ attitude

คำถามคลาสสิก: IS audit อยู่ Line ไหน? → Third Line

Trap: Auditor ทำงานเป็น Line อื่นแทน#

ใน scenario ของข้อสอบ ISACA ชอบเล่นกับ trap นี้:

Scenario: ฝ่าย IT ขอให้ internal audit ช่วยออกแบบ control ใหม่ + train พนักงานใช้ — auditor ตกลงไหม?

คำตอบ: ไม่ — เพราะ auditor ที่ออกแบบ control + train = ทำหน้าที่ของ Second Line (และ First Line) → independence หายเมื่อต้องกลับมาตรวจ control ที่ตัวเองออกแบบ

(ยกเว้นใน CSA — Control Self-Assessment ที่ auditor เป็น facilitator ไม่ใช่ owner — ดู ตอน 04)

Pattern ที่เจอบ่อย#

หลายบริษัทมองว่า security = หน้าที่ของ CISO + IT — board ไม่ engage

ผลลัพธ์: ถ้าไม่มี breach board ก็ไม่รู้ว่า security ดีหรือไม่ดี — และถ้ามี breach board ก็ตอบ stakeholder ไม่ได้ เพราะไม่เคยเข้าใจ security posture ของตัวเอง

Information Security Governance ที่ดี#

• Board = อนุมัติ risk appetite ของ security, รับ report เป็นรายไตรมาส (ไม่ใช่ปีละครั้ง)
• CEO = accountable ต่อ security outcomes ทั้งบริษัท
• CISO = implement security strategy, report ขึ้น board
• IS audit = ประเมินความเหมาะสมของ governance + control

CISO Reporting Line — Trap#

Trap: CISO รายงานต่อ CIO

ทำไม trap? เพราะ CIO มีแรงจูงใจให้ระบบ uptime สูงสุด (ผลงาน CIO) — แต่ security บางทีต้อง take down ระบบเพื่อแก้ vulnerability ถ้า CISO รายงาน CIO โดยตรง CISO อาจถูกบีบให้ลด priority security เพื่อรักษา uptime

Best practice: CISO รายงาน CEO หรือ board — ไม่อยู่ใต้ CIO

(แต่ในความเป็นจริง บริษัทขนาดกลางหลายแห่ง CISO ยังอยู่ใต้ CIO — ในกรณีนั้น auditor ต้องดู compensating control เช่น CISO มี dotted line รายงานตรงต่อ audit committee เป็นรายไตรมาส)

IT Strategy Committee#

• อยู่ระดับ Board — สมาชิกคือกรรมการบริษัท + ที่ปรึกษา
• หน้าที่: แนะนำ board ในเรื่อง IT strategic direction
• ขอบเขต: ระยะยาว 3-5 ปี
• ไม่ตัดสินใจเอง — แค่ advise board
• ตัวอย่างเรื่องที่คุย: “บริษัทควร migrate ไป cloud ภายใน 3 ปีมั้ย”, “ควร invest ใน AI หรือไม่”

IT Steering Committee#

• อยู่ระดับ Management — สมาชิกคือ CIO + business unit leaders
• หน้าที่: ตัดสินใจ + execute เรื่อง IT operations + projects
• ขอบเขต: ระยะใกล้ 1-2 ปี
• ตัดสินใจเอง — ภายในกรอบที่ board approve
• ตัวอย่างเรื่องที่คุย: “Project ERP ใหม่จะ go-live เมื่อไหร่”, “Budget ของ project อะไรเกิน”

ความต่างที่ออกข้อสอบ#

Test ในข้อสอบ: “Project ERP มีปัญหา budget เกิน — ใครต้องตัดสินใจ?” → Steering Committee (เป็นเรื่อง execution ไม่ใช่ strategic direction)

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

CIO — Chief Information Officer

• ดู IT operations + governance ทั้งบริษัท
• Report ขึ้น CEO (best practice) ไม่ใช่ CFO

CISO — Chief Information Security Officer

• ดู security ของบริษัท
• Report ขึ้น CEO หรือ board (best practice)

Data Owner — เจ้าของข้อมูล

• คือ business manager ที่รับผิดชอบ data — ไม่ใช่ IT
• มีอำนาจตัดสินว่าใครเข้าถึง data ได้
• กำหนด classification ของ data

Data Custodian — ผู้ดูแลข้อมูล

• คือ IT (DBA, system admin) ที่ เก็บและปกป้อง data ตาม classification ของ owner
• ไม่มีอำนาจตัดสิน access — แค่ implement ตามที่ owner สั่ง

Trap คลาสสิก: “DBA approve การให้ developer access ระบบ production”

ผิด — DBA = custodian ไม่มีอำนาจอนุมัติ access Data owner (business) ต้องเป็นคนอนุมัติ DBA แค่ทำตาม

SoD — Separation of Duties#

SoD = แบ่งหน้าที่สำคัญ ระหว่างคนหลายคน เพื่อให้ ไม่มีคนเดียวที่ทำได้ครบทุกขั้นตอนของกระบวนการที่ critical

หลักการ: 3 หน้าที่ที่ห้ามรวมในคนเดียวกัน:

• Custody — ครอบครอง asset
• Authorization — อนุมัติ
• Recording — บันทึกบัญชี/log

ตัวอย่าง: cashier ที่นับเงิน, อนุมัติคืนเงิน, ปิดบัญชีกะ ทั้งหมดในคนเดียว = ทำทุจริตได้ง่าย เพราะไม่มี cross-check

ในมุม IT:

• คนสร้าง user account ≠ คนอนุมัติ access ≠ คนใช้ access
• คน develop code ≠ คน deploy ไป production
• DBA ไม่ควร approve การ access ของตัวเองไป production

SoD ในบริษัทเล็ก — ทำไม่ได้ ทำยังไง?#

หลายบริษัทไทยขนาดกลางเล็กมาบ่นว่า “ทีมไม่พอจะแยก SoD ได้”

CISA ตอบว่า: ถ้าแยกไม่ได้ → ต้องมี compensating controls

เช่น:

• ผู้บริหารระดับสูงทำ review ทุกสัปดาห์ (แทนการแยกหน้าที่)
• log monitoring ที่เข้มกว่าปกติ
• บังคับ mandatory leave (เปิดเผยถ้ามีการทำงานผิดปกติ)

SoD ห้ามต่อรองในหลักการ — ห้ามต่อรองในการ implement compensating controls

Mandatory Leave — Control ไม่ใช่สวัสดิการ#

อีก trap ที่ออกข้อสอบ: mandatory leave (บังคับลา) เป็น control mechanism ไม่ใช่ HR benefit

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

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

EA คืออะไร?#

Enterprise Architecture = เอกสารที่ map ของ:

• ระบบ IT ทั้งหมดของบริษัท
• ความสัมพันธ์ระหว่างระบบ
• Data flow
• Business process ที่ใช้ระบบเหล่านั้น
• People + skills ที่ต้องการ

นึกง่าย ๆ คือ “แผนที่เมือง” ของ IT ในองค์กร

Framework ที่ต้องรู้จัก#

Zachman Framework — กรอบที่บอกว่า EA ต้องมีหลายมุมมอง (จากระดับยุทธศาสตร์ลงไประดับเทคนิค) — แต่ละ stakeholder เห็นมุมต่างกัน เหมือนแบบของสถาปนิกที่มี structural drawing, electrical plan, conceptual sketch — อาคารเดียวกันแต่หลายเอกสาร

TOGAF + ADM — methodology สำหรับสร้าง + maintain EA

ถ้าจะให้คำที่ติดหู:

• Zachman = layout ของแผนที่ (มุมมองอะไรบ้างต้องมี)
• TOGAF = กระบวนการสร้างแผนที่ (วาด, ทบทวน, อัปเดตยังไง)

ทำไม EA สำคัญสำหรับ Auditor?#

ถ้าไม่มี EA — auditor ตรวจ control แบบ ไม่รู้ขอบเขต

ลองดู:

• บริษัทบอกว่า “เรามี firewall ป้องกัน traffic” — auditor ถามต่อ “firewall ครอบคลุมระบบอะไรบ้าง?”
• ถ้าไม่มี EA → ตอบไม่ครบ → อาจมี shadow IT ที่ไม่ได้ผ่าน firewall เลย
• ถ้ามี EA → ดูแผนที่ → รู้ว่าระบบไหนผ่าน firewall, ระบบไหนไม่ผ่าน, ระบบไหนไม่อยู่ใน inventory เลย

Trap: EA ที่ไม่ update → ใช้แผนที่เก่า → auditor ตรวจตามแผนที่เก่า → finding หายไปทั้งหน้าใน landscape ที่เปลี่ยน

EA ต้องเป็น เอกสารที่มีชีวิต — update ทุกครั้งที่ system landscape เปลี่ยน