ฐานรากของ Domain 5 — Security Policy hierarchy (organizational/system-specific/issue-specific), framework selection, baselines, และ physical/environmental controls ที่หลายองค์กรลืมตรวจเพราะดูเรียบง่ายเกินไป

Storyboard ของ Domain 5 — Domain ที่ใหญ่ที่สุดในซีรีส์ ใช้ metaphor 'บ้านดิจิทัล' เป็นแกนเดียวร้อย 15 sections เข้าด้วยกัน ตั้งแต่กฎบ้าน ประตู กุญแจ ถนน ตู้เซฟ ไปจนถึงระบบดับเพลิงและตำรวจสืบสวน — ก่อนเจาะรายละเอียด 11 บทถัดไป

ปิด Domain 4 ทั้งหมด — recap 11 ตอน 16 sections (รวม Hardware Review Program, EDI/EDIFACT/X12, IS Operations, DAM, Classification of Operations 4-tier, BCP test 3 vs DR test 5), 5 บทเรียนสำคัญที่ Domain 4 ฝังในหัว, และเกริ่น Domain 5 ที่จะมาเรื่อง Security — ปกป้องระบบและข้อมูลที่เพิ่ง run ผ่านกันมา

Section 4.15 + 4.16 — บทใหญ่ที่สุดของซีรีส์ CISA: BCP (organization-wide) vs DRP (IT tactical), RPO vs RTO ที่ exam หลอกบ่อย, hot/warm/cold/mirror site ที่ต้องเลือกตาม BIA, BCP test 3 ระดับ vs DR test 5 ระดับ (คนละชุดกัน), Pandemic + Black Swan, Interruption Window + Orphan/Catch-up data, IS auditor checklist สำหรับ BCP/DRP, insurance ที่เป็น component ของ BCP — และทำไม reciprocal agreement = bad idea

Section 4.13 + 4.14 — resilience (clustering, telecom redundancy) ทำให้ระบบไม่ล่ม + backup ทำให้ข้อมูลไม่หายเมื่อระบบล่มจริง บทนี้คุย active-active vs active-passive, ransomware ที่กิน sync backup, และทำไม backup ที่ไม่เคย restore = false security

Section 4.12 — เปิด Part B (Business Resilience) ด้วย BIA ที่เป็นรากของ resilience decision ทุกตัว ER triage analogy + ที่ผู้บริหารต้องนั่งร่วม ไม่ใช่ปล่อยให้ IT ทำเอง

Section 4.11 — database คือโกดังที่เก็บคำตอบของทุกคำถามทางธุรกิจ DBA คือคนที่มีกุญแจทุกดอก ใครคุม DBA? บทนี้คุย DBMS architecture, ACID, field-level access, DBA bypass risk, และ backup encryption

Section 4.9 + 4.10 — log = ความจำขององค์กร ที่ทำให้ตอบได้ว่าเกิดอะไรขึ้น และ SLA = สัญญาที่วัดบริการได้จริง บทนี้คุยเรื่อง log integrity, SIEM ที่ตั้งค่าผิด, outsourced SLA ที่ไม่เคย verify

Section 4.8 — outage ส่วนใหญ่ไม่ได้มาจาก hacker หรือ hardware แต่มาจาก change ที่เราทำเอง บทนี้คุยทุกแง่ของ change/patch/config management ที่ exam ออกถาม emergency change, backout plan, และ CMDB

Section 4.6 + 4.7 — capacity management ป้องกันก่อนล่ม, incident management กู้คืนเมื่อล่ม, problem management หาต้นตอเพื่อไม่ให้ล่มซ้ำ ที่ exam ชอบหลอกว่า incident กับ problem คือเรื่องเดียวกัน — มันไม่ใช่

ข้อมูลที่หาย/ผิด/รั่ว ส่วนใหญ่เกิดตอนเดินทางระหว่างระบบ ไม่ใช่ตอนนิ่งใน database ตอนนี้คุย Section 4.4 (System Interfaces) + 4.5 (Shadow IT/EUC) — สองเรื่องที่ผมเรียกว่า รอยต่อทางการ และ รอยต่อใต้ดิน

ปูพื้น 3 เรื่องโครงสร้างของ Part A — USB ที่เป็นประตูหลังที่ network firewall มองไม่เห็น, IT Asset Management ที่ทุก control เริ่มจากการรู้ว่ามีอะไร, และ Job Scheduling ที่ทำงานเงียบๆ ทุกคืน. (OSI 7 Layer + Network primitives ที่เคยอยู่ในตอนนี้ ย้ายไปอยู่ใน Cybersecurity Foundation EP.26.5 เป็น primer ที่อ่านก่อนได้)

บทเปิด Domain 4 — หลังจาก D3 ปั้นระบบจน go-live ตอนนี้ระบบอยู่ในสนาม ทำงานทุกวัน เจอแรงกระแทกทุกแบบ Domain 4 คือเรื่องของ Run + Survive: ทำให้ทำงานต่อเนื่อง + รอดเมื่อเกิดเหตุไม่คาดคิด

Section 3.8 — Postimplementation Review (PIR) ที่ปิด governance loop ที่เปิดไว้ตั้งแต่ business case ทำไม PIR ต้องรอ 6-12 เดือน, ทำไม independence ของ auditor PIR สำคัญที่สุด, project closure 5 ขั้น พร้อม recap Domain 3 ทั้ง 8 ตอน + 5 บทเรียนสำคัญ และเกริ่น Domain 4 ที่จะคุยเรื่อง 'ระบบที่ build เสร็จแล้ว ดูแลให้ทำงานยังไง'

Section 3.6 + 3.7 — วันที่ความเสี่ยงสูงสุดของโปรเจ็คทั้งหมด ครอบคลุม configuration management (CMDB, baselines, check-in/check-out), data migration architecture (Unload-Cleanse-Transfer-Load), changeover techniques (parallel, phased, abrupt), rollback plan ที่ต้องทดสอบจริง และ end-user training ที่ไม่ใช่กิจกรรมท้ายสุด

Section 3.5 — testing classifications (unit, integration, system, recovery, security, performance), QAT vs UAT, ทำไม UAT ห้าม delegate ให้ vendor และ IS auditor's own tools (ITF, GAS, SCARF, snapshot, parallel simulation) ที่เป็น CAATs ในมุม SDLC พร้อม data integrity testing + certification process ก่อน go-live

Section 3.4 — application controls ที่ทดสอบบ่อยที่สุดในข้อสอบ Input controls (edit checks, batch totals, source authorization), Processing controls (run-to-run totals, exception reports, reasonableness), Output controls (distribution, retention, reconciliation) พร้อมเรื่อง DBA bypass — application controls แข็งแค่ไหน ก็ไม่มีความหมายถ้าฐานข้อมูลถูกแก้ตรง

Section 3.3.5 — methodology ที่ไม่ใช่ waterfall ทุกแบบมี risk profile คนละเรื่อง Agile ไม่ใช่ no documentation, Prototype ไม่ใช่ production after approval, RAD ไม่ใช่แค่ shortened waterfall, DevOps ไม่ใช่ทำให้ change control หาย OOSD เป็น programming paradigm ไม่ใช่ methodology ของโปรเจ็ค auditor ต้องตรวจคนละจุดในแต่ละแบบ

Section 3.3 phases 1-3 + 3.3.7-3.3.9 — SDLC แบบ waterfall ที่ทุก methodology อื่นใช้เป็น baseline เปรียบเทียบ พร้อมเรื่องการซื้อระบบ: RFP/ITT, vendor evaluation, source code escrow, right-to-audit clause และเหตุผลที่ buyer ต้องทดสอบเอง — ห้าม delegate ให้ vendor

Section 3.1 + 3.2 — ก่อนจะเริ่มสร้างระบบ ต้องมี governance structure (sponsor, steering committee, PM, PMO), business case ที่วัดได้, และ feasibility study ที่เปรียบเทียบทางเลือกอย่างซื่อตรง บทนี้รวม WBS, Gantt, CPM, PERT, EVA และเรื่องที่ IS auditor มักพลาดที่สุด — independence ที่หายไปเมื่อเข้าไปอยู่ในทีมโปรเจ็ค

เปิด Domain 3 — ก่อนจะลงรายละเอียด SDLC, methodology หลายแบบ, application controls, testing, migration และ postimplementation review ผมขอวาด map ทั้ง domain ก่อน — ตั้งแต่วันที่ business โยนไอเดียมา จนถึงวันที่ระบบขึ้น production แล้วยังต้องมีคนกลับมาตรวจอีกรอบ

ปิด Domain 2 — recap ทั้ง 9 ตอน, 5 บทเรียนสำคัญที่ Domain 2 ฝังในหัว (Accountability ไม่ transfer, Governance vs Management, วงจรไม่หยุด, Independence = Structural, Documentation = Asset) บวกเกริ่น Domain 3 ที่เปลี่ยนเรื่องไปยัง 'สร้าง IT system ใหม่'

QA vs QC ที่คนใช้สลับกันตลอด, QA Independence ที่ต้อง structural ไม่ใช่แค่ stated, Quality Management ที่ทำให้ process เป็น repeatable, Operational Excellence — ที่มาของ continuous improvement บวก trap คลาสสิก: developer review code ตัวเอง

วัด IT performance ที่ไม่ใช่แค่ตัวเลขบน dashboard — KPI (จะถึงเป้ามั้ย), KRI (เสี่ยงเพิ่มขึ้นมั้ย), KGI (control ทำงานจริงมั้ย) — 3 ตัวที่บอกคนละเรื่อง บวก PDCA cycle และ IT Balanced Scorecard ที่ทำให้ board เห็น IT ครบทุกมิติ

Outsourcing เป็น sourcing ที่ใหญ่ที่สุดของ IT ในยุคนี้ — แต่ผู้บริหารเข้าใจผิดบ่อยที่สุดว่า 'ส่งออกแล้วไม่ต้องรับผิดชอบ' จริง ๆ accountability ไม่ transfer สัญญา outsourcing ที่ดี + SOC report + right-to-audit + cloud governance + concentration risk