Map ของ Domain 2 — 9 ตอน#

Part A (ตอน 14-17): “Foundation of Governance” — ตัวกฎ + โครงสร้าง + ความเสี่ยง + ข้อมูล

Part B (ตอน 18-21): “Operational Governance” — คน + เงิน + vendor + measurement + quality

ภาพ Mental Model ทั้ง Domain#

1
[ External: Laws + Regulations + Industry Standards ]
2
           ↓ (translated by org into)
3
[ Internal: Policies → Standards → Procedures → Guidelines ]
4
           ↓ (governed through)
5
[ EGIT — Board responsibility ]
6
   ├── Governance Committees (Strategy + Steering)
7
   ├── Three Lines Model (Operational / Risk / Audit)
8
   ├── Roles + SoD (Data Owner vs Custodian)
9
   └── Enterprise Architecture (the map)
10
           ↓ (protects against)
11
[ Risks → ERM lifecycle (Identify/Assess/Respond/Monitor) ]
12
   ├── Privacy Program (Personal Data subset)
13
   └── Data Governance + Classification (all data)
14
           ↓ (operationalized through)
15
[ Resource Management (HR / Change / Financial / Security) ]
16
   └── Vendor Management (outsourced functions)
17
           ↓ (measured by)
18
[ Performance Monitoring (KPI / KRI / KGI / PDCA / BSC) ]
19
           ↓ (quality assured by)
20
[ QA + Quality Management + Operational Excellence ]
21
           ↓ (independently assessed by)
22
[ IS Auditor (Third Line) ]

นี่คือทั้ง โลก ของ Domain 2 — ทุก concept อยู่ในแผนผังนี้

1. Accountability ไม่ Transfer#

ไม่ว่าจะ outsource ไปกี่ vendor ไม่ว่าจะใช้ cloud หนักแค่ไหน ไม่ว่า committee จะตั้งกี่ชุด — ความรับผิดชอบสุดท้ายต่อ stakeholder ยังอยู่กับองค์กร

นี่คือ theme ที่กลับมาในหลายตอน:

• ตอน 16 — EGIT = board responsibility (ไม่ใช่ของ CIO)
• ตอน 19 — outsourcing โอน execution ไม่โอน accountability
• ตอน 17 — risk acceptance ต้อง document, ไม่ใช่ “ปล่อย”

ผู้บริหารที่เข้าใจประโยคนี้ — outsource อย่างมี governance ผู้บริหารที่เข้าใจผิด — outsource เพื่อหลีกเลี่ยงความรับผิดชอบ (และจะเจอความผิดหวังเมื่อเกิดเหตุ)

2. Governance ≠ Management#

เส้นแบ่ง 2 คำที่คนใช้สลับตลอด:

• Governance = board เป็นคนทำ — กำหนดทิศทาง, อนุมัติ risk appetite, monitor outcome
• Management = CIO + ทีม — execute ตามทิศทาง, run day-to-day

ทุก trap ของ Domain 2 ที่เกี่ยวกับ committee, role, structure มี root อยู่ที่นี่:

• IT Strategy Committee (board level — advise) ≠ IT Steering Committee (management level — execute)
• EGIT (board) ≠ IT operations (CIO)
• Risk appetite (board approves) ≠ Risk tolerance per category (operational)

3. วงจรไม่หยุด#

Risk management ไม่ใช่ทำครั้งเดียว Privacy program ไม่ใช่ post notice แล้วจบ Vendor management ไม่ใช่เซ็น contract แล้วจบ Performance measurement ไม่ใช่ collect ตัวเลขครั้งเดียว — ทุกอย่างคือ วงจร ที่ต้อง monitor + improve ต่อเนื่อง

ตัวอย่าง pattern ของ “วงจรไม่หยุด” ใน Domain 2:

• ERM lifecycle — Identify → Assess → Respond → Monitor → (loop)
• PDCA — Plan → Do → Check → Act → (loop)
• Vendor governance — Due diligence → Contract → Monitor → Review → (loop)
• Privacy program — Inventory → Notice → Train → Audit → Update → (loop)

บริษัทที่ทำ governance เป็น project (เริ่ม–จบ) → governance หายไปเมื่อ project หมดแรง บริษัทที่ทำ governance เป็น culture (ต่อเนื่อง) → governance ปรับตัวตาม environment ที่เปลี่ยน

4. Independence = Structural ไม่ใช่ Attitude#

ใน Domain 1 เราเรียนเรื่อง audit independence — Domain 2 เราเห็นว่า principle เดียวกัน apply ที่อื่น ๆ ของ governance:

• Audit Independence (ตอน 02 — D1) — รายงานต่อ audit committee ไม่ใช่ CFO
• CISO Reporting (ตอน 16) — ไม่ควรอยู่ใต้ CIO
• QA Independence (ตอน 21) — ไม่อยู่ใต้ development manager
• Data Owner vs Custodian (ตอน 17) — DBA ไม่ approve access ตัวเอง
• SoD (ตอน 16) — Custody ≠ Authorization ≠ Recording

ทุกกรณี — โครงสร้าง enforce independence ในระยะยาว ไม่ใช่ความตั้งใจของบุคคล

ในบริษัทเล็กที่ทำไม่ได้ทาง structural → compensating controls (ไม่ใช่ skip)

5. Documentation = Asset#

หลายผู้บริหารมอง documentation เป็น overhead — เปลืองเวลา ไม่ generate revenue

แต่ Domain 2 ฝังในหัวว่า documentation = asset ของ governance:

• Policy ที่ไม่ document = ไม่มีใครรู้ว่ามี = control ที่ไม่มีอยู่จริง
• Procedure ที่ไม่ document = process ขึ้นกับคน = หายไปเมื่อคนลาออก
• Risk acceptance ที่ไม่ document = neglect ในมุม auditor
• PIA ที่ไม่ document = compliance ที่พิสูจน์ไม่ได้
• Training ที่ไม่ document = “พนักงานเรารู้แล้ว” ที่ไม่มี evidence
• SOC report จาก vendor = ระบบ documentation ที่ทำให้ accountability ไม่หายเมื่อ outsource

ถ้าไม่มี documentation = control ไม่มีอยู่ในมุม auditor

นี่คือ litmus test ที่กลับมาตลอด Domain 2

Mental Model ของ Domain 3#

ลองคิดว่า Domain 1+2 เป็นการเตรียมความพร้อมเชิงระบบ — ตอนนี้ business ของเรามี idea ว่าจะสร้างระบบใหม่ (เช่น app ใหม่, ระบบ ERP ใหม่, AI platform ใหม่)

จาก idea → ระบบที่ go-live ใน production มี lifecycle ที่ยาว:

1
Idea → Feasibility → Design → Build/Acquire → Test → Deploy → Review

Domain 3 จะคุยทุก phase นี้ — ในมุม IS auditor ที่เข้าไปตรวจ project ตั้งแต่ต้นจนจบ

หัวข้อที่จะมาใน Domain 3#

Cross-references จาก Domain 2 ที่จะกลับมา#

• Project governance ใน Domain 3 → ใช้ EGIT framework จาก Domain 2 ตอน 16
• Vendor evaluation ใน acquisition → ใช้ knowledge จาก Domain 2 ตอน 19 (Vendor Management)
• Right-to-audit clause ใน software acquisition → จาก Domain 2 ตอน 19
• Project risk → ใช้ ERM framework จาก Domain 2 ตอน 17
• Test data privacy → จาก Domain 2 ตอน 17 (developer ห้าม access production data)

ถ้า Domain 2 แน่น Domain 3 จะอ่านไหลขึ้นมาก เพราะ governance ที่ Domain 2 วางไว้คือ constraint ที่ project ของ Domain 3 ทำงานภายใต้

Trap Patterns ที่ Domain 3 จะมา#

แย้มไว้ก่อน:

• IS auditor ที่ joining project = consultant ไม่ใช่ auditor (independence ที่หาย)
• WBS = deliverable-based ไม่ใช่ task-based
• Steering Committee ≠ Project Manager
• Agile ≠ no documentation
• Vendor ทำ testing ของซอฟต์แวร์ที่ขายให้บริษัท ≠ เพียงพอ — บริษัทต้อง test เอง