1. BIA คือต้นน้ำของทุก Resilience Decision#

ในมุมที่ผมว่าสำคัญที่สุดของ D4 — ทุกตัวเลขใน Part B downstream จาก BIA

• RTO ของ DRP — มาจาก BIA
• RPO และ backup frequency — มาจาก BIA
• เลือก hot/warm/cold site — มาจาก RTO ที่มาจาก BIA
• BCP scope — มาจาก critical process ที่มาจาก BIA

ถ้า BIA weak → ทุก downstream control ก็ inadequate

ถ้า BIA strong → resilience ทั้งระบบจะมีรากที่แน่น

คำถาม audit แรกของผมเสมอ: “BIA ครั้งล่าสุดของท่านทำเมื่อไหร่ ใครเป็น sponsor?“

2. Control Gap มักอยู่ที่ “รอยต่อ”#

control gap ในระบบใหญ่ — ไม่ได้อยู่ในระบบ มันอยู่ระหว่างระบบ:

• Interfaces (ตอน 33) — ข้อมูลส่งผิดระหว่างระบบ
• Shadow IT (ตอน 33) — ข้อมูลออกนอก official IT
• Logs ไม่มีคนอ่าน (ตอน 36) — บันทึกแล้วเสียเปล่า
• Backup ไม่เคย restore (ตอน 39) — promise ที่ไม่รู้ว่าทำได้รึเปล่า
• BCP ไม่เคยซ้อม (ตอน 40) — กระดาษที่ไม่มีค่า

จุดร่วม — ทั้งหมดคือ control ที่ “มีในทฤษฎี, fail ตอน implement”

3. Test เท่านั้นที่พิสูจน์ Control#

list ที่ผมเรียกว่า “promise without proof”:

• backup ที่ไม่เคย test restore → ไม่รู้ว่า restore ได้
• BCP ที่ไม่เคย test → ไม่รู้ว่า team ทำตามได้
• hot site ที่ไม่เคย test → ไม่รู้ว่า hardware ตรงกับ production
• patch ที่ไม่เคย test ใน staging → ไม่รู้ว่าจะ break อะไร
• DRP ที่ไม่เคย test → ไม่รู้ว่า procedure executable
• failover plan ที่ไม่เคย test → ไม่รู้ว่า cluster ทำงานจริง

กฎง่ายๆ: untested control = อาจเป็นอย่างที่คิด หรืออาจไม่เป็น — ไม่มีทางรู้ ในมุม audit untested = inadequate

4. Automation = Systemic Risk#

ใน D4 ระบบ automate เยอะ — job scheduler, interface, batch job, replication

ลด human error แต่สร้าง new risk:

• error 1 ตัว × scale ใหญ่ = หายนะ ใหญ่
• silent failure — fail แต่ไม่มี alert
• human ไม่ได้ใส่ใจ — เพราะ “ระบบ auto จัดการ”

จุดที่ต้อง audit ใน automated system:

• exception handling
• alerting
• manual override authority + log
• reconciliation ระหว่าง automated output กับ expected

5. Document ที่ไม่ Maintain = ภาระ ไม่ใช่ control#

เอกสารที่ไม่ update มี 3 ปัญหา:

• False confidence — คนคิดว่ามีแล้ว เลยไม่ตรวจอีก
• Legal risk — ตอน regulator ถามเจอว่า outdated → worse than no document
• Operational risk — ตอนเหตุเกิดจริง ใช้ document ที่ผิด → ผิดทาง

ตัวอย่างที่เจอตลอดบทนี้:

• Asset register outdated → ไม่รู้ว่ามีอะไรในระบบ
• CMDB ไม่ accurate → ไม่รู้ว่า config ปัจจุบันคืออะไร
• BCP contact list outdated → ตอนเหตุเกิด call ไม่ติด
• DRP procedure outdated → ทำตามแล้วไม่ work

กฎ: document ที่ไม่มี named owner + ไม่มี review schedule → ไม่ใช่ control

Theme 1 — Lifecycle: Prevent → Detect → Respond → Recover#

D4 ทุกบทอยู่ในหนึ่งใน 4 phase นี้:

control ที่ดี = ครอบ 4 phase ไม่ใช่ phase เดียว

Theme 2 — Business นำ IT support#

ในเกือบทุก section ของ D4:

• BIA — business เป็นคน define criticality
• SLA — business เป็นคน define service level ที่ต้องการ
• Capacity planning — business growth ขับ IT capacity
• BCP — board level decision

IT ที่ดี = IT ที่รู้ตำแหน่งของตัวเอง — เป็น enabler ไม่ใช่ decision maker

Theme 3 — Trust + Verify ผ่าน Audit Trail#

ทุก control ใน D4 ที่จับต้องได้ — ผ่าน audit trail:

• Change log
• Console log จาก scheduler
• Database access log
• BCP test record
• Restoration test result
• Vendor SLA report

ถ้าทำแล้ว — ต้องบันทึก ถ้าไม่บันทึก = ไม่มีทางพิสูจน์ว่าทำ