BCP = ทั้งองค์กร / DRP = เฉพาะ IT#

ความแตกต่างที่ exam ออกซ้ำๆ:

ความสัมพันธ์: DRP เป็น component หนึ่งของ BCP

ถ้าเขียน hierarchy:

1
BCP (ทั้งบริษัท)
2
├── DRP (IT recovery)
3
├── Crisis communication plan (สื่อสาร)
4
├── Supply chain continuity plan
5
├── HR continuity (relocate, work-from-home)
6
└── Facility recovery plan

Trap ที่ exam ออก — “BCP = IT’s job”#

ผิดเด็ดขาด BCP คือ board / senior management responsibility

IT รับผิดชอบ DRP ที่เป็น component ของ BCP แต่ BCP เป็นเรื่องของทั้งองค์กร

ถ้า org ไหน “BCP = IT department’s plan” → finding ทันที

ตัวอย่างจริง: น้ำท่วม 2554#

โรงงานในนิคมที่ปทุมธานี มี BCP เก่า 3 ปีที่ assume worst case = ไฟดับ 2 วัน

ตอน flood 2554 โรงงานจม 6 สัปดาห์

BCP ที่มี ไม่ใช่ผิดทั้งหมด แต่ไม่ครอบ scenarioที่เกิดจริง:

• ไม่มีแผน relocate พนักงาน
• ไม่มีแผน remote payroll
• ไม่มีแผนสื่อสารกับ supplier ระหว่าง 6 สัปดาห์
• ไม่มี procedure เคลม insurance
• ไม่มี contingency operating ที่โรงงานสำรองพื้นที่อื่น

BCP มีอยู่ แต่ scope ผิด focus เฉพาะ technical incident ไม่ครอบ catastrophic scenario เลย

นี่แหละสิ่งที่ผมว่าต้องจำให้แม่น#

Restaurant fire analogy#

ลองนึกถึงร้านอาหารเกิดไฟไหม้ครับ มี 2 คำถามที่ต่างกัน:

คำถามแรก: “บัญชีรายรับรายจ่ายที่จดไว้ในกระดาษ — เราเสียได้ย้อนหลังเท่าไหร่?”

ถ้าจดทุกชั่วโมง backup → เสียอย่างมาก 1 ชั่วโมง = RPO = 1 ชั่วโมง ถ้าจดทุกวันสรุปวันเดียว → เสียอย่างมาก 1 วัน = RPO = 1 วัน

คำถามที่สอง: “ร้านต้องเปิดอีกครั้งภายในเท่าไหร่ ก่อนจะเสียลูกค้าทั้งหมด?”

ถ้าเป็นร้านแถบ business district → 1 วันก็เริ่มสูญลูกค้าประจำ = RTO = 1 วัน ถ้าเป็นร้านในชุมชนเล็กๆ → 1 สัปดาห์ยังพอ = RTO = 1 สัปดาห์

RPO กับ RTO ต่างกันยังไง?

• RPO = “ข้อมูลที่ recover ได้ ย้อนได้ไกลแค่ไหน”
• RTO = “ใช้เวลานานแค่ไหนถึงกลับมา”

ระบบหนึ่งสามารถมี RPO 4 ชั่วโมง แต่ RTO 1 ชั่วโมงก็ได้ ยอม lose data 4 ชั่วโมงล่าสุด แต่ต้องกลับมาบริการใน 1 ชั่วโมง

Trap pattern#

Pattern ที่เห็นใน practice question ของ CISA บ่อย:

“ระบบมี RPO 2 ชั่วโมง — backup ทุก 24 ชั่วโมงพอมั้ย?”

ไม่พอครับ RPO 2 ชั่วโมง = ยอม lose data ย้อนได้ 2 ชั่วโมง ต้อง backup อย่างน้อยทุก 2 ชั่วโมง (หรือใช้ replication)

“ระบบมี RTO 1 ชั่วโมง — restore จาก tape ที่ใช้เวลา 4 ชั่วโมงพอมั้ย?”

ไม่พอ restore ต้องเร็วกว่า RTO ถึงจะ work

MTTR — ตัวเลขที่เกี่ยวข้อง#

อีกตัวที่บางครั้ง exam ออก: MTTR (Mean Time To Repair) = เวลาเฉลี่ยในการแก้ระบบที่ fail

MTTR ต่ำ → recovery เร็ว → support RTO ที่สั้นกว่า

แต่ MTTR ขึ้นกับ complexity ของ system, parts availability, skill ของช่าง

Other parameters: MTO + SDO#

Mirror Site#

คือ: copy ของ production แบบ real-time — ทั้ง hardware, software, data sync ตลอดเวลา ทำงานเหมือน production ทุกประการ

RPO / RTO: ใกล้ 0 / ใกล้ 0

ราคา: สูงสุด เหมือนมี production 2 ชุดเลย

ใช้กับ: ระบบ ultra-critical (ตลาดหุ้น, payment processing ของธนาคารใหญ่, monitoring system ของ ICU)

Hot Site#

คือ: site ที่พร้อมใช้งาน — มี hardware, software, network ทุกอย่าง data sync แต่อาจมี delay บ้าง

RPO / RTO: ชั่วโมง / น้อยกว่า 4 ชั่วโมง (โดยทั่วไป)

ราคา: สูง ค่า maintain hardware + software license + ค่า facility ครบ

ใช้กับ: ระบบ Mission Critical ที่ acceptance downtime สั้น

Warm Site#

คือ: site ที่มี hardware + network แต่ software / data ต้อง install + restore ก่อนใช้

RPO / RTO: วัน / 1-3 วัน (โดยทั่วไป)

ราคา: กลาง

ใช้กับ: ระบบ Important ที่ทนได้บ้าง

Cold Site#

คือ: ห้องเปล่าที่มี power + network เฉยๆ ทุกอย่างต้องขนเข้าไปติดตั้งหลังเกิดเหตุ

RPO / RTO: สัปดาห์ / 1+ สัปดาห์

ราคา: ต่ำสุด

ใช้กับ: ระบบ low priority ที่ทนได้นาน

Mobile Site#

คือ: truck/container ที่บรรจุ IT equipment พร้อม deploy ที่ไหนก็ได้ ใช้ตอนที่ primary site เสียหายและไม่มีพื้นที่ทดแทน

Reciprocal Agreement — ห้ามใช้สำหรับ critical system#

คือ: ข้อตกลงระหว่าง 2 องค์กร ตกลงให้ใช้ facility ของอีกฝ่ายได้ตอน disaster

ฟังดูดีนะ แต่exam ออกชัดเจนว่า reciprocal agreement = ไม่แนะนำสำหรับ critical system เพราะ:

• Capacity — partner องค์กรมี capacity พอจริงมั้ย?
• Compatibility — hardware/software/version ตรงกันมั้ย?
• Security — ข้อมูลของเราจะ co-mingle กับของ partner
• Licensing — software license ของเราใช้ใน partner site ได้มั้ย?
• Politics — partner อาจเปลี่ยน mind ตอนเกิดเหตุจริง

กรณีจริง: Hot site ที่ไม่ exclusive#

ธนาคารภูมิภาคไทยแห่งหนึ่ง มีสัญญา hot site ที่สีลม

หลายปีที่ผ่านมาไม่เคย test เลย

วันที่เกิด fire ใน data center หลัก ธนาคาร declare disaster, contact hot site provider

provider แจ้งว่า มีอีก 3 บริษัท declare disaster พร้อมกัน, hot site เต็ม อ้าว

สัญญาของธนาคารไม่มี exclusivity clause ต้องรอ 18 ชั่วโมง

control gap:

• ไม่เคย test hot site
• สัญญาไม่มี exclusivity ระหว่าง simultaneous disaster
• ไม่ได้ verify subscriber limit ของ provider

สิ่งที่ต้องอยู่ในสัญญา recovery site#

ขอ list ที่ผมว่าสำคัญที่สุดสำหรับ exam:

1. Exclusive access หรือ subscription-based (priority ของเรา)
2. Capacity guarantee — รับประกันว่ามี hardware พอ
3. Time guarantee — declare ตอนใด ใช้งานตอนใด
4. Duration — ใช้ได้นานสุดเท่าไหร่
5. Test rights — ทดสอบกี่ครั้งต่อปี
6. Configuration update — ใครรับผิดชอบ update hardware/software ใน hot site
7. Confidentiality — security ของ data ที่อยู่ใน site
8. Liability — ใครรับผิดถ้า hot site เสียหาย
9. Termination — เงื่อนไขเลิกสัญญา
10. Insurance — coverage ของ provider

Key Decision-Making Personnel — ใครมีอำนาจตัดสินตอนวิกฤต#

ตอน BCP ถูก activate จริง ใครเป็นคนตัดสินใจเรื่องใหญ่?

• ใครประกาศ “นี่คือ disaster” และ activate BCP?
• ใครตัดสินใจ failover ไป recovery site?
• ใครคุยกับ regulator?
• ใครให้ข่าวกับสื่อ?

ถ้าไม่ตอบล่วงหน้า ตอนเกิดเหตุจริงจะปั่นป่วนมาก เพราะทุกคนรอคำสั่ง

BCP ที่ดีระบุ:

• Primary decision maker + alternate (เผื่อคน primary ติดต่อไม่ได้)
• Authority limit — ใครอนุมัติ spending ระดับไหนได้
• Succession order — ลำดับสำรอง 3-4 ชั้น ไม่ใช่แค่ primary + alternate
• Contact information — เบอร์มือถือ, home phone, alternate email — verify เป็นระยะ

Crisis Communication Plan#

CRM แยก crisis communication เป็น component ของตัวเอง ไม่ใช่ส่วนเล็กๆ ของ DRP

ตอน disaster เกิดจริง บริษัทต้อง communicate กับ:

• พนักงาน — มาทำงานที่ไหน ทำอะไร ขั้นตอน safety
• ลูกค้า — service จะ resume เมื่อไหร่ ผลกระทบยังไง
• Supplier / partner — supply chain disruption + timeline
• Regulator — บางอุตสาหกรรมต้อง notify ภายในเวลากำหนด (ธปท., ก.ล.ต., PDPA office)
• Insurance — claim filing timeline
• Media / public — single spokesperson ที่ approved พูดได้

กับดักของ exam: “ทุกคนใน management พูดกับ media ได้” ผิด crisis communication ต้องมี single spokesperson ที่ approved + briefed message ที่ consistent ห้ามมีหลายเสียง confuse + เกิด liability

Insurance Coverage#

อีกเรื่องที่ CRM 4.15.8 ระบุชัด — insurance เป็น component ของ BCP

ประเภท insurance ที่เกี่ยวข้องกับ IT disaster:

• Property insurance — coverage hardware, facility damage
• Business interruption insurance — coverage revenue loss ระหว่าง downtime
• Cyber liability insurance — coverage breach response, regulatory penalty, third-party claims
• Errors & Omissions (E&O) — coverage liability ที่เกิดจาก IT service ผิดพลาด

กฎเหล็ก: insurance ไม่ทดแทน BCP มัน complement กัน BCP กู้คืน operations, insurance shoulder financial loss

มุม IS Auditor#

3 จุดที่ตรวจ:

• Coverage adequacy — coverage limit ครอบคลุม worst-case scenario ของ BIA ไหม
• Policy currency — policy ยังไม่หมดอายุ + premium จ่ายครบ
• Claim procedure — ทีม BCP รู้ขั้นตอนเคลม + เอกสารที่ต้องเตรียม + timeline

ตัวอย่างจริง: บริษัทแห่งหนึ่งซื้อ cyber liability insurance แต่ตอน ransomware เกิด ไม่ได้ notify insurer ภายใน 72 ชั่วโมงตามที่ policy ระบุ → claim ถูกปฏิเสธ เลย

policy ที่ดีที่สุดในโลก = ไม่มีค่า ถ้า claim procedure ไม่ถูก execute

กระดาษที่ไม่เคยซ้อม = ไม่มีค่า#

ตัวอย่างจริงที่ยากเลย: hospital เอกชนที่กรุงเทพ annual BCP tabletop test

ระหว่าง test พบว่า:

• emergency contact list มี 12 เบอร์ที่เป็นเบอร์เก่า (พนักงานออก/เปลี่ยนเบอร์)
• backup site access code เป็นของ vendor ที่หมดสัญญา 8 เดือนก่อน
• ไม่มีใคร update ตั้งแต่เขียน BCP เสร็จ

ถ้าเกิดเหตุจริง BCP ใช้ไม่ได้เลย

control gap: ไม่มีคน assign รับผิดชอบ BCP maintenance

BCP / DR Testing: 5 ระดับที่ exam ออกชัด#

CRM แบ่ง testing เป็น 5 ระดับ ที่ ascending ใน realism + risk + cost:

ระดับที่ 1 — Paper / Checklist Test#

คือ: review เอกสาร BCP/DRP — verify ว่า contact list, procedure, resource list ยัง current

ข้อดี: เร็วสุด, ราคาถูกสุด — ทำได้บ่อย (รายเดือน / รายไตรมาส) ข้อจำกัด: ไม่ test ความเข้าใจหรือ execution — แค่ดูเอกสาร

ระดับที่ 2 — Tabletop / Walk-through Test#

คือ: ทีมนั่งคุยกันรอบโต๊ะ — ไล่ scenario, อ่าน BCP ทีละขั้น, discuss role

ข้อดี: test ความเข้าใจ + role clarity, low cost ข้อจำกัด: ยัง paper — ไม่ได้ execute จริง

ใช้ตอน: ปีละ 1-2 ครั้ง, train new member

ระดับที่ 3 — Preparedness / Walk-through Drill#

คือ: ทำตาม procedure ในส่วนหนึ่งของ BCP จริง — เช่น activate emergency contact tree, evacuation drill, test backup generator startup, แต่ไม่ failover production

ข้อดี: เจอ gap ของ procedure จริง (เบอร์โทร outdated, generator ไม่ start, เอกสาร access ไม่ทัน) ข้อจำกัด: test เฉพาะส่วน ไม่ end-to-end

ใช้ตอน: ปีละ 1-2 ครั้ง สำหรับ critical procedure

ระดับที่ 4 — Simulation Test / Parallel Test#

คือ: simulate disaster scenario เต็มรูปแบบ — failover ไป backup site, run system แบบ parallel กับ production, เปรียบเทียบ result โดยที่ production ยัง serve user จริง

ข้อดี: test end-to-end recovery + verify backup site ทำงาน ข้อจำกัด: resource หนัก — ทีมต้อง support ทั้ง production + recovery site พร้อมกัน

ใช้ตอน: ปีละครั้ง สำหรับระบบ critical

ระดับที่ 5 — Full Operational Test / Full Interruption#

คือ: failover จริง — ปิด production, switch ไป backup site, run business จริงจาก backup site ระยะหนึ่ง

ข้อดี: ที่สุดของ realism — ทุก dependency, ทุก human factor, ทุก timing ถูก test ข้อจำกัด: risky — ถ้า fail = outage จริง ต้องการ approval ระดับ board

ใช้ตอน: สำหรับ regulated industry (banking, healthcare) ที่ regulator require, ทำในช่วง low-business window

Trap ของ exam — “tabletop = full test”#

ผิดเด็ดขาด tabletop = ระดับ 2, full operational = ระดับ 5 คนละ realism กันเลย

ถ้าองค์กรทดสอบเฉพาะ tabletop → flag finding เพราะ procedure ที่อยู่บนกระดาษอาจ break ตอน execute จริง

กฎ progression: องค์กรไม่ควรกระโดดจาก paper → full operational ทันที ต้องไต่ระดับ ใช้ผลของ test ระดับล่างมา fix ก่อน escalate

BCP Maintenance: triggers ที่ต้อง update#

BCP ต้อง update เมื่อ:

• พนักงาน turnover ในตำแหน่งที่อยู่ใน emergency contact
• ระบบ IT ใหม่ go-live
• ระบบเก่าเลิกใช้
• regulatory requirement เปลี่ยน
• vendor ที่ระบุใน BCP เปลี่ยน
• business process เปลี่ยน
• หลัง test เจอ gap
• หลังเหตุจริงเกิด

ที่ดีที่สุด — มี named owner ที่รับผิดชอบ BCP maintenance + quarterly review

กรณีจริงที่ misclassify#

convenience store chain — มี ransomware affect 3 ร้านใน 1 เขต

incident response team escalate เป็น crisis → activate ทั้ง BCP

กลายเป็นว่าทุก resource ของ crisis response team ทุ่มไปที่ ransomware ใน 3 ร้าน

ระหว่างนั้น payment network outage ที่กระทบทั้ง 200 ร้านเกิดขึ้น แต่ทีมหลักไม่ว่าง ต้องให้ทีม junior จัดการ

result: misclassify ของ event แรก → ทรัพยากรไม่พอสำหรับ event ที่ใหญ่กว่า อ้าว

บทเรียน: classification criteria ต้องชัด + objective ไม่ใช่ subjective judgment ของคนตอบโทรศัพท์คนแรก

RPO vs RTO#

BCP vs DRP#

Recovery Sites#

Testing#