CISA Series ตอนที่ 38 : D4 - เปิด Part B — BIA: ก่อนวางแผนรอด ต้องรู้ว่าอะไรสำคัญ

จบ Part A ไปแล้วครับ — 6 ตอน (32-37) ที่ครอบเรื่องการ “Run” ระบบในวันธรรมดา

ตอนนี้เปิด Part B: Business Resilience — เรื่องที่ตอบคำถาม “Survive” — เมื่อเกิดเหตุที่ระบบล่มจริงๆ องค์กรรอดยังไง?

แต่ก่อนจะคุยเรื่อง BCP, DRP, hot site, RPO/RTO — ผมต้องคุยคำถามแรกก่อน:

“คุณรู้รึยังว่าอะไรคือสิ่งที่สำคัญที่สุดในธุรกิจของคุณ?”

ฟังดูเหมือนคำถามง่ายๆ — แต่จริงๆ แล้วมันคือคำถามที่หลายองค์กรตอบไม่ได้

และคำตอบของคำถามนี้ = BIA (Business Impact Analysis)

ทำไม BIA เป็น gateway ของ Part B#

ลองนึกถึง ER ของโรงพยาบาล — เมื่อมีอุบัติเหตุใหญ่ มีคนไข้มาพร้อมกัน 20 คน

ถ้า ER ตอบสนองทุกคนเท่าๆ กัน — คนที่ critical ที่สุดอาจตายระหว่างรอ ถ้า ER ทุ่มทรัพยากรให้คนที่ไม่ critical — คนที่ต้องการช่วยจริงๆ ไม่ได้รับการช่วย

ER ที่ดี — มี triage ก่อนเสมอ จัดประเภทตามความ critical:

Red — life-threatening, ต้องช่วยทันที
Yellow — serious, ช่วยภายใน 30 นาที
Green — stable, รอได้
Black — deceased

triage ทำตอนไหน? — ทำเมื่อคนไข้เข้ามา triage ใช้ข้อมูลจากที่ไหน? — จาก protocol ที่เตรียมไว้ก่อนเกิดเหตุ

ถ้า ER ไม่มี triage protocol pre-set → ตอนเกิดเหตุจริงจะตัดสินใจไม่ทัน

BIA = triage protocol ของระบบ IT

ก่อนเกิดเหตุ — เราต้องรู้ว่า:

ระบบไหน critical (red) — ทนได้ < 1 ชั่วโมง
ระบบไหน important (yellow) — ทนได้ 1-24 ชั่วโมง
ระบบไหน secondary (green) — ทนได้ > 24 ชั่วโมง

ตอนเกิดเหตุจริง — เรารู้ว่ากู้คืนอะไรก่อน

BIA ตอบ 3 คำถามใหญ่#

BIA ที่ทำเสร็จต้องตอบได้:

คำถามที่ 1 — กระบวนการอะไรที่ critical?#

ไม่ใช่ “ระบบ IT” — แต่เป็น business process

เช่น โรงพยาบาล process critical คือ — emergency care, surgery scheduling, medication dispensing ระบบ IT ที่ support process เหล่านี้ — EMR, pharmacy system, lab system

ลำดับ logic: business process critical → IT system ที่ support → infrastructure ที่ support → backup site ที่ต้องเตรียม

ถ้าเริ่มจาก IT system โดยไม่ผ่าน business process → คุณตอบคำถาม “What” ก่อน “Why” — ผิดลำดับ

คำถามที่ 2 — ทนได้นานแค่ไหน?#

เรียกว่า Critical Recovery Period

นี่คือคำถามที่ business ตอบ ไม่ใช่ IT ตอบ:

โรงพยาบาล emergency: 0 นาที (ห้ามล่ม)
ธนาคาร payment: 1-2 ชั่วโมง (รับได้สั้นมาก)
ร้านเบเกอรี่ POS: ครึ่งวัน (ใช้กระดาษแทนได้)
HR system: 1-3 วัน (จ่ายเงินเดือน 15/30 ของเดือน)

ตัวเลขนี้จะกลายเป็น RTO ในขั้นต่อไป (จะคุยในตอน 40)

คำถามที่ 3 — ถ้าล่ม เสียหายเท่าไหร่?#

ต้นทุนของ downtime — measure 4 มิติ:

Revenue loss — รายได้ที่หายไประหว่าง downtime
Penalty — ค่าปรับตามสัญญา / กฎหมาย
Operational cost — overtime, manual fallback, contractor
Reputation — long-term effect (ลูกค้าหาย, brand damage)

ตัวเลขเหล่านี้ = base ของ cost-benefit analysis ของ resilience investment

วิธีทำ BIA: 3 approach#

CRM อธิบาย 3 วิธี ผมขอเล่าตามเรียงระดับความ thorough:

Approach 1 — Questionnaire#

ส่งแบบสอบถามให้ business unit owner ตอบ — เร็ว, scale ได้, แต่ความลึกจำกัด

ใช้ตอน — ต้อง assess หลาย business unit พร้อมกัน, time-constrained

Approach 2 — Interview#

นั่งคุยตัวต่อตัวกับ owner ของแต่ละ process — ลึก, capture nuance, แต่ใช้เวลาเยอะ

ใช้ตอน — process critical, ต้องเข้าใจ context

Approach 3 — Hybrid (recommended)#

questionnaire ส่งทุกคน → interview เฉพาะ unit ที่ถูก flag เป็น critical จาก questionnaire

ดีที่สุดในส่วนใหญ่ — balance ระหว่าง coverage กับ depth

ใครควรทำ BIA?#

นี่คือเรื่องที่หลายองค์กรทำผิด

ผิด: BIA = IT department ทำ#

หลายองค์กรมอบ BIA ให้ IT ทำเอง — IT จะ assess priority ของระบบ จากมุม IT

ปัญหา: IT ไม่รู้ว่าธุรกิจทนอะไรได้นานแค่ไหน

ตัวอย่างจริง: ผู้ผลิตอาหารแห่งหนึ่งที่นครราชสีมา — IT ทำ BIA เองโดยไม่คุยกับ HR

IT classify ERP เป็น “high priority”, HR system เป็น “low priority”

ตอน flood — บริษัทพบว่า payroll ของ HR ต้องรันวันที่ 15 และ 30 ตามกฎหมายแรงงานไทย จ่ายช้า = labor law violation + worker unrest

control gap: BIA ไม่มีคน HR participate

ถูก: BIA = senior management + business unit owner ทำ#

BIA ที่ work ต้องการ:

Executive sponsor — CEO/COO ที่ provide authority + drive participation
Business unit owner — แต่ละ unit ส่ง representative ที่รู้ business จริง
IT facilitator — ช่วย translate business requirement เป็น IT capability
Risk/audit observer — ช่วยตั้งคำถามที่ challenge assumption

IT ไม่ใช่คนทำ — IT คือผู้ช่วย

มุมผู้บริหาร: BIA เป็น board-level discussion ไม่ใช่ IT project

BIA ต้อง update เมื่อไหร่?#

ที่หลายองค์กรพลาด — ทำ BIA ครั้งเดียวเมื่อ 5 ปีที่แล้ว แล้วไม่เคยกลับมาดู

stale BIA = อันตรายกว่าไม่มี BIA เพราะให้ false confidence

trigger ที่ต้อง update BIA:

ระบบใหม่ go-live
ระบบเก่าเลิกใช้
Business expansion / new market
Regulatory change ที่ส่งผลต่อ availability requirement
Outsourcing arrangement ใหม่
Major incident ที่ reveal gap
Org restructuring

ตัวอย่าง: โรงพยาบาลทำ BIA เมื่อ 2 ปีก่อน — patient management system “ทนได้ 4 ชั่วโมง”

6 เดือนต่อมา — โรงพยาบาลได้ JCI accreditation ที่ require 99.9% uptime สำหรับ clinical system

BIA outdated ทันที — ต้อง re-assess

Third-party dependency ใน BIA#

จุดที่หลายองค์กรลืม — process ที่ outsource

ถ้า payment processing ใช้ third-party provider — BCP ของบริษัทเรา ต้องครอบคลุมสถานการณ์ที่ third-party นี้ล่มด้วย

ตัวอย่างจริง: convenience store chain ที่ classify payment processing เป็น Mission Critical (RTO = 1 ชั่วโมง)

แต่ BIA ไม่ครอบ scenario ที่ payment network provider (third-party) ล่ม

วันที่ provider ล่มจริง — store มี BCP สำหรับ internal failure แต่ไม่มีสำหรับ external provider failure

control gap: BIA ไม่ครอบ third-party dependency

เชื่อม ตอน 19 (Vendor Management) — vendor’s DRP ต้องเป็นส่วนหนึ่งของ BIA

Cost-benefit framework ของ BCP investment#

อีกผลผลิตของ BIA = ตัดสินใจว่า invest ใน resilience เท่าไหร่จึงคุ้ม

แนวคิด simple — มี 2 cost ที่ trade-off กัน:

Cost of downtime — ยิ่ง downtime นาน ยิ่งเสียหาย (เพิ่มเรื่อยๆ)
Cost of resilience — ยิ่งต้องการ recovery เร็ว ยิ่งแพง (เพิ่มเรื่อยๆ ตามจาก cold→warm→hot site)

จุดที่ optimal = ตรงที่ total cost (downtime + resilience) ต่ำสุด

ถ้า downtime cost ต่ำ → cold site / late recovery พอ ถ้า downtime cost สูง → hot site / instant failover

Auditor’s note: CISA exam จะไม่ถามให้คำนวณตัวเลขจริง — แต่จะถามว่าองค์กรทำcost-benefit analysis รึเปล่า

Trap pattern ของข้อสอบเรื่อง BIA#

หลุมพราง	คำตอบที่ถูก
”BIA = ทำครั้งเดียว”	ต้อง update เมื่อระบบ/ regulator/ business เปลี่ยน
”IT decide criticality”	criticality = business decision — IT support
”RPO = RTO”	RPO = data loss tolerance, RTO = downtime tolerance — คนละมิติ
”low priority = ไม่ต้องมี BCP”	low priority = recovery window ยาวกว่า ไม่ใช่ไม่ต้องมี
”BIA cost analysis = audit จะ test”	auditor verify ว่าทำ ไม่ test ตัวเลขเอง

Cross-domain connection#

หัวข้อ	เชื่อมไป
Risk-based thinking ทั่วองค์กร	ตอน 17 (D2 ERM)
Vendor BCP	ตอน 19
RTO/RPO detail	ตอน 40 (จะตามมา)
BCP / DRP development	ตอน 40

ปิดบท: BIA = compass ของ Part B ทั้งหมด#

ที่ผมพยายามจะ flag ตอนเปิด Domain 4 แล้ว — และจะ flag อีกครั้งที่นี่:

ทุก decision ของ Part B downstream จาก BIA

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

ถ้า BIA ผิด — ทุก decision ที่ตามมาผิด

ถ้า BIA strong — Part B ทั้งหมดจะมีรากที่แน่น

ในมุม auditor ผม — เริ่มจาก BIA เสมอเวลาตรวจ resilience ของ organization ใหม่ ถ้า BIA หรือไม่ครบ → ทำนายได้เลยว่าทุก downstream control จะ inadequate

ตอนถัดไปเราจะลง 2 layer ของ resilience preparation — System Resilience (clustering, telecom redundancy) ที่ทำให้ระบบไม่ล่ม + Backup ที่ทำให้ข้อมูลไม่หาย เมื่อระบบล่มจริงๆ

อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 4: Section 4.12 Business Impact Analysis