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 ทั่วองค์กร	ตอน 17A (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