สารบัญ
ขึ้น Domain 4 แล้วครับ — และผมขอยอมรับตรงๆ ว่านี่คือ Domain ที่ผมตั้งใจอ่านที่สุดในทั้งซีรีส์
เหตุผลง่ายๆ: D4 น้ำหนักข้อสอบ 26% ใหญ่สุดร่วมกับ D5 มี section ทั้งหมด 16 sections (มากที่สุดในทุก Domain) และเป็น Domain ที่ผมเชื่อว่าใกล้เคียงกับงานจริงของ IS auditor มากที่สุด — เพราะมันคือเรื่องของ ระบบที่อยู่ในสนามจริง ไม่ใช่ระบบบนกระดาน
ก่อนจะลงรายละเอียด ผมขอใช้บทนี้วาดแผนที่ใหญ่ก่อน — แบบเดียวกับที่ทำใน ตอน 03 สำหรับ D1, ตอน 14 สำหรับ D2, และ ตอน 23 สำหรับ D3
ที่ผ่านมาเรารู้อะไรแล้ว
ลองย้อนภาพรวมทั้งซีรีส์ก่อน — เพราะ D4 ไม่ใช่ Domain ที่อยู่โดดเดี่ยว มันต่อยอดจากทุก Domain ก่อนหน้า
- Domain 1 — วิธีของ auditor: รู้กฎ มีอำนาจ วางแผนตามความเสี่ยง ลงสนาม เก็บหลักฐาน ออก report
- Domain 2 — สรีระของ organization ที่ดี: governance, ERM, policy hierarchy, vendor management, performance
- Domain 3 — กระบวนการสร้างระบบใหม่: business case, SDLC, application controls, testing, go-live, post-implementation review
- Domain 4 — ระบบที่ go-live แล้ว ดูแลยังไง รอดยังไง — ที่กำลังจะคุยกัน
- Domain 5 — ปกป้องระบบและข้อมูลจากการถูกโจมตี (รออยู่)
ทุก Domain ต่อกันแน่น — D4 รับมาจาก D3 ที่ระบบเพิ่ง go-live ส่วน D5 จะมารับช่วงต่อในมิติ security
คำถามใหญ่ของ D4 — Run + Survive
D3 จบลงตรงไหน? ตรงที่ระบบใหม่ผ่าน UAT, migrate ข้อมูลเข้าได้ครบ, เปิดให้ user ใช้งาน, ผ่าน post-implementation review
แล้วต่อจากนั้นล่ะ?
จากนั้นระบบ อยู่ในสนาม — มีคนใช้งานจริง 8 ชั่วโมงต่อวัน 365 วันต่อปี มีข้อมูลไหลเข้าออกตลอดเวลา มี integration กับระบบอื่น มี vendor มาเสริม มี patch ใหม่ออกทุกเดือน มีพนักงานใหม่เข้ามา มีพนักงานเก่าออกไป มีเซิร์ฟเวอร์ที่อายุเริ่มเก่า มีปริมาณข้อมูลที่โตขึ้น
แล้วก็จะมีวันที่ — ระบบช้า, ระบบแฮ้ง, ระบบเพี้ยน, serverล่ม, น้ำท่วม data center, hard driveพัง, พนักงานกดผิด, hackerเข้ามา, vendorผิดสัญญา
D4 คือคำตอบของ 2 คำถามที่อยู่คู่กันตลอด:
- Run — ทำยังไงให้ระบบทำงานสม่ำเสมอทุกวัน ไม่ล่มก่อนเวลา
- Survive — เมื่อเกิดเหตุที่ระบบล่มจริง รอดมาได้ยังไง
ในมุม business owner — D4 คือเรื่องของ continuity (ธุรกิจไม่หยุด) และ resilience (เจ็บแล้วยังลุกได้)
ในมุม auditor — D4 คือเรื่องของการตรวจว่า control ที่อยู่รอบๆ การ run + survive มีครบและทำงานจริงรึเปล่า
โครงของ Domain 4 — 16 sections แบ่งเป็น 2 parts
CRM แบ่ง D4 เป็น 2 ส่วนใหญ่ๆ:
Part A — Information Systems Operations (Section 4.1-4.11): เรื่องของการ “Run” ระบบในวันธรรมดา
Part B — Business Resilience (Section 4.12-4.16): เรื่องของการ “Survive” เมื่อเกิดเหตุ
ผมจะ map สั้นๆ ก่อนว่าแต่ละ section คุยเรื่องอะไร แล้วตอนถัดๆ ไปจะเจาะทีละส่วน
Part A: Run — งานประจำที่ทำให้ระบบทำงาน
เรื่องที่ Part A คุยกัน เรียงตามลำดับที่ผมจะเล่า:
| ขั้น | เรื่อง | คำถามใหญ่ |
|---|---|---|
| รู้จักโครงสร้าง | OSI Model + LAN/WAN + USB + Asset Inventory + Job Scheduling | auditor ต้องอ่านโครงสร้าง IT ให้ออกก่อนตรวจอะไรเลย |
| รอยต่อ | System Interfaces + Shadow IT | ข้อมูลหายไปไหนระหว่างระบบ — รอยต่อมักเป็นจุดอ่อน |
| เมื่อระบบมีปัญหา | Capacity + Incident + Problem Management | ป้องกันก่อนล่ม / กู้คืนเมื่อล่ม / เลิกล่มซ้ำ |
| เมื่อต้องเปลี่ยนแปลง | Change + Configuration + Patch Management | ทำไมระบบดีๆ ถึงพังหลัง update |
| ความจำขององค์กร | Log Management + SLA | จดทุกเหตุการณ์ไว้ + วัดบริการได้ |
| โกดังข้อมูล | Database Management | ใครคุม DBA ที่มีกุญแจทุกดอก |
จะเห็นว่า Part A เริ่มจาก infrastructure ก่อน → operations process → data layer
ในมุมผม — Part A คือเรื่องของ “ความสม่ำเสมอ” ระบบที่ดีไม่ใช่ระบบที่ไม่เคยมีปัญหา แต่เป็นระบบที่จัดการปัญหาได้สม่ำเสมอ
Part B: Survive — แผนเมื่อเกิดเหตุ
Part B สั้นกว่าแต่หนักกว่า เพราะนี่คือส่วนที่ exam ออกข้อสอบหนัก:
| ขั้น | เรื่อง | คำถามใหญ่ |
|---|---|---|
| รู้ว่าอะไรสำคัญ | BIA — Business Impact Analysis | ก่อนวางแผนรอด ต้องรู้ก่อนว่าอะไรสำคัญ + ทนได้นานแค่ไหน |
| สร้างความพร้อม | Resilience + Backup | ระบบไม่ล่ม + ข้อมูลไม่หาย — สองชั้นความพร้อม |
| เมื่อเกิดเหตุจริง | BCP + DRP + RPO/RTO + Recovery Sites | แผนตอนเกิดเหตุ + กลยุทธ์การฟื้นฟู |
Part B มี logic ลำดับชัดเจน — BIA เป็นต้นน้ำ ทุกอย่างไหลตามมา ถ้า BIA ผิด ทุก decision ที่ตามมา (RTO, RPO, จะเลือก hot site หรือ cold site, จะลงทุน backup แบบไหน) ก็ผิดหมด
4 Theme ที่ผมเจอใน D4
ก่อนจะลงตอน 32 ผมขอ flag 4 theme ที่ขึ้นมาซ้ำๆ ตลอด D4 — รู้ไว้แล้วเวลาอ่านบทถัดๆ ไปจะจับแก่นได้เร็วขึ้น
Theme 1 — Lifecycle: Prevent → Detect → Respond → Recover
D4 ไม่ใช่ list ของ control แต่เป็น lifecycle ที่ control ต่างๆ อยู่ในตำแหน่งที่ต่างกัน:
- Prevent (ก่อนเหตุ) — change management, capacity planning, asset inventory ทำให้เหตุไม่เกิด
- Detect (ตอนเหตุเริ่ม) — log monitoring, alert จาก SIEM, threshold ของ capacity เริ่มเตือน
- Respond (ตอนเหตุเกิด) — incident management ตอบสนองเฉพาะหน้า กู้บริการคืน
- Recover (หลังเหตุ + ระยะยาว) — problem management หาต้นตอ, BCP/DRP กู้คืนระยะยาว
control ที่ดีไม่ใช่ control ที่ป้องกันได้ทุกอย่าง — มันคือ control ที่ ครอบทุก phase ของ lifecycle ถ้าองค์กร invest แต่ Prevent ไม่ invest Detect → ตอนเกิดเหตุจะไม่รู้ตัว
Theme 2 — Control Gap มักอยู่ที่ “รอยต่อ”
จุดที่ control พังบ่อยสุดไม่ใช่ภายในระบบ — แต่อยู่ที่รอยต่อ:
- ข้อมูลส่งจากระบบ A ไประบบ B (interface)
- ข้อมูลที่อยู่นอก official IT (Shadow IT, Excel ของฝ่ายบัญชี)
- log ที่บันทึกแล้วไม่มีคนอ่าน
- backup ที่มีแล้วไม่เคย test restore
- BCP ที่เขียนแล้วไม่เคยซ้อม
Auditor ที่เก่ง — รู้ว่าจะหา finding ตรงไหนก่อน คำตอบคือ รอยต่อ เสมอ
Theme 3 — BIA คือต้นน้ำของทุก resilience decision
ถ้าจำได้แค่อย่างเดียวจาก D4 ขอให้จำเรื่องนี้ — BIA นำ, ทุกอย่างตาม
ใครจะตัดสินใจว่า:
- ระบบนี้ต้องกู้คืนภายในกี่ชั่วโมง? (RTO)
- ข้อมูลย้อนหลังกี่ชั่วโมงที่ยอมเสียได้? (RPO)
- ต้องลงทุน hot site หรือ cold site พอ?
- ต้อง backup ทุกชั่วโมงหรือทุกวัน?
ทั้งหมดนี้ตอบได้ก็ต่อเมื่อ — BIA ทำเสร็จ + business เป็นคนตอบเอง ไม่ใช่ IT
Theme 4 — Automation = Systemic Risk
ใน D4 ระบบ auto-mate เยอะมาก: job scheduler รันงานคืนละหลายพัน, interface ส่งข้อมูลระหว่างระบบทุก 5 นาที, batch job คำนวณเงินเดือน, replication ทำ backup real-time
automation ลด human error — แต่สร้างความเสี่ยงใหม่: เมื่อ error เกิด มันเกิดที่ scale ใหญ่และเงียบ
ตัวอย่าง: ถ้าคน 1 คนกดผิด 1 ครั้ง = 1 record ผิด แต่ถ้า batch script กดผิด 1 บรรทัด = 50,000 record ผิด และไม่มีใครรู้ทันที
D4 บังคับให้ auditor มอง automation เป็น risk เฉพาะตัว — ตรวจ control ของกระบวนการที่ auto-mate ไม่ใช่แค่กระบวนการที่ทำมือ
บทเรียนใหญ่ที่ผมเก็บได้ตอนเรียนทั้ง Domain
มีอยู่ 3 ความเข้าใจที่ผมว่าเป็น “key” ของทั้ง D4:
1. Operations ดูเหมือนเรื่องเทคนิค แต่ตัวตัดสินใจคือ business
จะวาง capacity เท่าไหร่, จะลงทุน hot site มั้ย, RTO ควรเป็นเท่าไหร่ — ทุกอย่างนี้เป็น business decision ที่อาศัยข้อมูล technical ประกอบ ไม่ใช่กลับกัน
2. Test เท่านั้นที่พิสูจน์ว่า control ทำงาน
backup ที่ไม่เคย restore, BCP ที่ไม่เคยซ้อม, hot site ที่ไม่เคย test — ทั้งหมดนี้คือ control ที่อยู่ในกระดาษ ไม่ได้อยู่ในความเป็นจริง
3. Document ที่ไม่มีคน maintain เป็นภาระ ไม่ใช่ control
asset register ที่ไม่ update, BCP contact list ที่ outdated, CMDB ที่ไม่มีใครแก้ — เอกสารพวกนี้ให้ false sense of security ที่อันตรายกว่าการไม่มีเลย
ลำดับ 11 ตอนที่จะเล่าใน D4
ผมตัดสินใจ restructure ลำดับ CRM ให้เล่าเรื่องต่อเนื่องดีกว่า — ไม่ได้ตามเลข section เป๊ะๆ แต่อยู่ใน 16 sections ครบ
Part A — Operations ในวันธรรมดา (ตอน 32-37)
- ตอน 32 — โครงสร้าง IT ที่ auditor ต้องเข้าใจ (OSI + USB + Asset + Job Scheduling)
- ตอน 33 — Interfaces + Shadow IT (รอยต่อที่มักหลุดมือ)
- ตอน 34 — Capacity + Incident + Problem (เมื่อระบบช้า/ล่ม)
- ตอน 35 — Change + Patch Management (ทำไมระบบดีๆ ถึงพังหลัง update)
- ตอน 36 — Log Management + SLA (Black Box ขององค์กร)
- ตอน 37 — Database Management (โกดังกับคนถือกุญแจ)
Part B — Business Resilience (ตอน 38-40)
- ตอน 38 — BIA (รู้ว่าอะไรสำคัญก่อนเกิดเหตุ)
- ตอน 39 — Resilience + Backup (สองระดับความพร้อม)
- ตอน 40 — BCP + DRP + RPO/RTO (บทใหญ่สุด)
ปิดท้าย
- ตอน 41 — ปิด D4 + Recap + เกริ่น D5 (Security)
ตอนนี้พร้อมแล้วครับ บทถัดไปจะเริ่มที่ infrastructure layer — OSI Model, USB risk, IT asset management, และ job scheduling ที่ทำงานอยู่ในเงา
ก่อนตรวจอะไรในระบบ auditor ต้องอ่านโครงสร้างของระบบให้ออกก่อน — เพราะถ้าอ่านโครงสร้างไม่เป็น เวลาเจอ finding จะไม่รู้ว่ามันมาจาก layer ไหนของระบบ
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 4: Section 4.1-4.16 (synthesis post — ภาพรวม Domain 4 ทั้งหมด ไม่ตรงกับ section ใด section หนึ่ง)
