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

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

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

แต่ก่อนจะคุยเรื่อง BCP (Business Continuity Plan / แผนบริหารความต่อเนื่องของธุรกิจ), DRP (Disaster Recovery Plan / แผนกู้คืนระบบหลังภัยพิบัติ), hot site, RPO (Recovery Point Objective / จุดเวลาที่ยอมเสียข้อมูล) / RTO (Recovery Time Objective / เวลาที่ยอมระบบล่ม) ขอคุยคำถามแรกก่อนครับ

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

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

คำตอบของคำถามนี้ก็คือ 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 ชั่วโมง

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

Classification of Operations — คำที่ CISA ใช้จริง#

ER triage analogy ที่เพิ่งใช้ — สีแดง / เหลือง / เขียว — ใช้คิดในใจดีมาก ภาพชัด เก็ตเร็ว

แต่พอเข้าห้องสอบ ISACA ไม่ถามว่า “ระบบนี้สีอะไร” ครับ ข้อสอบจะใช้ คำทางการ 4 ระดับ ที่ CRM กำหนดไว้ — Critical / Vital / Sensitive / Nonsensitive

ตอนสอบต้อง map analogy ER triage ในใจไปคำพวกนี้ให้ทันด้วย

ER triage (analogy)	CRM 4-tier official	ความหมาย	RPO/RTO ตัวอย่าง
สีแดง / วิกฤต	Critical	function ต้องกลับมาทันที — ทำ manual แทนไม่ได้ downtime = ธุรกิจล้ม	RPO < 1 ชม., RTO < 4 ชม.
สีเหลือง / สำคัญ	Vital	function สำคัญ — ทน downtime สั้นๆ ได้ ทำ manual ได้ชั่วครู่ ต้องกลับมาภายในไม่กี่วัน	RPO < 24 ชม., RTO < 48 ชม.
สีเขียวอ่อน / ทน	Sensitive	function ทำ manual ได้นานพอควร แต่ใช้คนเพิ่ม ระยะยาวคน burn out	RPO 1 สัปดาห์, RTO 1-2 สัปดาห์
สีเขียว / ไม่สำคัญ	Nonsensitive	function delay ได้นาน ไม่ค่อยกระทบ business	RPO/RTO เดือนขึ้นไป

ความต่างหลักของ 4 ระดับนี้ไม่ใช่แค่ “สำคัญมาก / น้อย” แต่อยู่ที่ว่า ทำ manual แทนได้รึเปล่า + ทนได้นานแค่ไหน ต่างหาก

Critical — manual แทนไม่ได้เลย (เช่น real-time trading, ICU (Intensive Care Unit / ห้องดูแลผู้ป่วยวิกฤต) monitoring)
Vital — manual ได้แต่สั้นๆ (เช่น payment processing ใช้กระดาษได้ 1-2 วันแล้วเริ่มพัง)
Sensitive — manual ได้นานแต่เปลือง (เช่น HR ใช้ Excel แทนได้ 1-2 สัปดาห์ คนทำงานล้นมือ)
Nonsensitive — delay ได้สบาย (เช่น internal training portal)

มุมข้อสอบ: ISACA ถามตรงคำ Critical / Vital / Sensitive / Nonsensitive — analogy ER triage ใช้คิดในใจ map กลับเองตอนเลือกข้อ ห้าม mix up Vital กับ Critical (เป็นหลุมพรางที่เจอบ่อย — function ที่ “ทำ manual ได้ชั่วครู่” = Vital ไม่ใช่ Critical)

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

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

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

ไม่ใช่ “ระบบ IT” นะครับ แต่เป็น business process ต่างหาก

เช่น โรงพยาบาล process critical คือ emergency care, surgery scheduling, medication dispensing ระบบ IT ที่ support process พวกนี้ก็ EMR (Electronic Medical Records / เวชระเบียนอิเล็กทรอนิกส์), 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 (Point of Sale / เครื่องคิดเงินหน้าร้าน): ครึ่งวัน (ใช้กระดาษแทนได้)
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 (Enterprise Resource Planning / ระบบบริหารทรัพยากรองค์กร) เป็น “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 (Chief Executive Officer) / COO (Chief Operating Officer) ที่ 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 (Joint Commission International — มาตรฐานสากลรับรองคุณภาพโรงพยาบาล) 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 รึเปล่า

ALE — ตัวเลขช่วย rank ว่าควรลงทุนอันไหนก่อน#

cost-benefit framework บอกแค่ “จุดที่คุ้ม” แต่พอมี scenario เสี่ยงหลายตัวพร้อมกัน — flood, cyberattack, vendor failure, hardware fail — ต้องตัดสินใจว่าลงทุนป้องกันตัวไหนก่อน เพราะงบไม่พอทำทุกเรื่องอยู่แล้ว

CISA ใช้ metric ชื่อ ALE (Annual Loss Expectancy) ครับ สูตรตรงๆ:

ALE = SLE × ARO โดย SLE = Single Loss Expectancy (เสียหายต่อ 1 ครั้งที่เกิด) และ ARO = Annualized Rate of Occurrence (โอกาสเกิดต่อปี)

ลองนึก scenario: cyberattack เสียหายครั้งละ 5 ล้านบาท (SLE) มีโอกาสเกิด 0.2 ครั้งต่อปี (ARO = ทุก 5 ปี) → ALE = 1 ล้านบาท/ปี เทียบกับ flood ที่ SLE 10 ล้าน × ARO 0.05 (ทุก 20 ปี) = ALE 500,000 บาท/ปี

scenario ที่ ALE สูงกว่า = ควรลงทุน control ก่อน เพราะความเสียหายคาดการณ์รายปีเยอะกว่า

มุมข้อสอบ: ISACA จะไม่ถามให้คำนวณตัวเลขเอง แต่จะถามว่า ALE ใช้ทำอะไร (= rank ลำดับ scenario ที่ควรลงทุน) และความต่างระหว่าง SLE กับ ARO

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 ทั้งหมดจะมีรากที่แน่น

ใน CISA exam ก็เห็นชัดเลย scenario เรื่อง resilience เกือบทุกข้อสุดท้ายจะวิ่งกลับมาที่คำถามว่า BIA ทำดีรึเปล่า ถ้า 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