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

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

ความสัมพันธ์: DRP (Disaster Recovery Plan / แผนกู้คืนระบบหลังภัยพิบัติ) เป็น component หนึ่งของ BCP (Business Continuity Plan / แผนบริหารความต่อเนื่องของธุรกิจ)

ถ้าเขียน 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 เลย

Creeping disaster — disaster ที่ค่อยๆ คืบมาเงียบๆ#

ก่อนข้าม pandemic ขอ flag ศัพท์เล็กๆ ที่ CRM 4.15.2 พูดถึง — creeping disaster = disaster ที่ค่อยๆ พัฒนาช้าๆ ไม่ใช่เกิดทันที

ตัวอย่างที่เห็นชัด:

• database performance ที่ค่อยๆ ช้าลงจนถึงจุดที่ไม่ usable
• data corruption ที่กัดกินทีละ record ผ่านไปหลายเดือนกว่าจะรู้
• ภัยแล้งที่ค่อยๆ แห้ง
• pandemic ที่ค่อยๆ ลามจาก local outbreak ไปทั่วโลก

ตรงข้ามกับ sudden disaster เช่น แผ่นดินไหว ไฟไหม้ flood — เกิดแล้วรู้ทันที

อันตรายของ creeping disaster คือ “ไม่มี clear trigger point” ให้ activate BCP — กว่าจะรู้ว่านี่คือ disaster ระบบก็เสียหายไปนานแล้ว

ตรงนี้แหละที่ monitoring tools + helpdesk ที่เป็น early warning system มีบทบาทสำคัญ — ตามที่ CRM ระบุ “many disruptions start as minor incidents” และ helpdesk ที่ดีคือคนแรกที่จับ pattern ผิดปกติได้

Pandemic planning — โรคระบาดไม่ใช่ disaster แบบ flood#

CRM แยก pandemic ออกเป็น scenario คนละแบบกับ disaster ปกติ เพราะ profile ของ disruption ต่างกันมากครับ:

• ยาวกว่ามาก — flood / ไฟไหม้ อาจกินสัปดาห์ ส่วน pandemic กินเดือนหรือเป็นปี
• กระทบทรัพยากรคน ไม่ใช่อาคาร — สำนักงานยังอยู่ดี แต่คนเข้ามาทำงานไม่ได้ / ป่วยพร้อมกัน / โดน quarantine
• ลามทั้ง supply chain + ลูกค้า + พนักงานพร้อมกัน — recovery site ปกติช่วยไม่ได้ เพราะคนที่ไปประจำ site ก็ป่วยเหมือนกัน

BCP สำหรับ pandemic ต้องเน้นต่างจาก disaster ทั่วไป — remote work readiness (VPN (Virtual Private Network / เครือข่ายส่วนตัวเสมือน) capacity, laptop deployment, secure home access), key-person redundancy ลึกกว่าปกติ (สำรอง 3-4 ชั้น เผื่อทั้ง chain ป่วยพร้อมกัน) และ supplier/customer communication plan สำหรับสถานการณ์ที่ไม่มีใครรู้ว่าจะจบเมื่อไหร่

Black Swan — เหตุที่ไม่มีใคร plan ทัน#

อีกประเด็นที่ CRM 4.15.2 พูดตรงๆ คือ Black Swan event — เหตุที่ไม่มีใครคาดได้ ผลกระทบใหญ่ และมักอธิบายได้ “หลังเกิดแล้ว” เท่านั้น

ตัวอย่างคลาสสิก: 9/11, COVID-19, financial crisis ปี 2008, แผ่นดินไหวที่กระทบ nuclear plant ของ Fukushima

ประเด็นของ Black Swan ใน BCP ไม่ใช่ “ทำ plan ครอบให้ครบ” (เป็นไปไม่ได้) แต่คือ:

• มี plan ที่ generic พอ ครอบ “loss of headquarters / loss of key supplier / loss of large % ของ workforce” ทั้ง 3 scenario โดยไม่ต้องตั้งคำถามว่าสาเหตุคืออะไร
• หลีกเลี่ยง single point of failure ที่ระดับคนด้วย เช่น ห้าม CEO (Chief Executive Officer) + COO (Chief Operating Officer) บินไฟลต์เดียวกัน
• review BCP กว้างหลัง event ใหม่ๆ ไม่ใช่แค่ update contact list

CRM พูดชัด — “เหตุพวกนี้หายาก แต่ถ้าเกิดอาจ paralyze องค์กรได้ management ต้องคิดถึง contingency แม้ในกรณีสุดโต่ง”

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

Restaurant fire analogy#

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

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

ถ้าจดทุกชั่วโมง backup → เสียอย่างมาก 1 ชั่วโมง = RPO (Recovery Point Objective / จุดเวลาที่ยอมเสียข้อมูล) = 1 ชั่วโมง ถ้าจดทุกวันสรุปวันเดียว → เสียอย่างมาก 1 วัน = RPO = 1 วัน

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

ถ้าเป็นร้านแถบ business district → 1 วันก็เริ่มสูญลูกค้าประจำ = RTO (Recovery Time Objective / เวลาที่ยอมระบบล่ม) = 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: Interruption Window + MTO + SDO#

Orphan data + Catch-up data + Disaster tolerance#

CRM 4.16.1 ทิ้ง 3 ศัพท์เล็กๆ ที่ exam ชอบหลอก ขออธิบายสั้นๆ ตรงนี้ครับ

ตอนเกิด disaster แล้ว restore กลับมา จะมีข้อมูล 3 กลุ่ม:

• Catch-up data — transaction ที่เกิดในช่วงตั้งแต่ backup ล่าสุดจนถึงตอน disaster ที่ต้อง re-enter หลัง recovery (ถ้ายังเก็บไว้ในกระดาษ / cache ที่หน้างานได้)
• Orphan data — ข้อมูลที่หายไปจริงๆ ไม่มีทาง recover ได้ ต่อให้ catch-up เสร็จก็ยังขาด คือ “RPO ที่ยังเหลือเป็นแผล” นั่นเอง
• Disaster tolerance — ช่วงเวลาที่ business ยังพอ “ทน” สถานะที่ระบบ IT critical ไม่พร้อมใช้ ยิ่ง RTO ต่ำ → disaster tolerance ต่ำ → ต้องลงทุน recovery หนักกว่า

ลองนึก ระบบ POS (Point of Sale / เครื่องคิดเงินหน้าร้าน) ของร้านสะดวกซื้อ RPO 1 ชั่วโมง backup ทุก 1 ชั่วโมง ถ้าระบบพังตอน 14:45 backup ล่าสุดคือ 14:00 → transaction ของ 14:00–14:45 ที่ขายไปแล้ว ถ้าใบเสร็จยังเก็บได้ก็เป็น catch-up data ถ้าใบเสร็จหายไปด้วย = orphan data

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 (Personal Data Protection Act / พรบ.คุ้มครองข้อมูลส่วนบุคคล) 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

ลองนึก scenario: บริษัทแห่งหนึ่งซื้อ 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 test vs DR test — คนละชุดกัน อย่าผสม#

จุดนี้คือจุดที่ผมเอง confuse นานมากครับ เพราะ CRM แยกเป็น 2 ชุดคนละชุดกัน:

• BCP test types (Section 4.15.9) = ฝั่ง ธุรกิจ ทดสอบว่าทั้งองค์กรพร้อมรับมือมั้ย มี 3 ระดับ
• DR test types (Section 4.16.5) = ฝั่ง IT recovery ทดสอบว่าระบบ failover ทำงานจริงมั้ย มี 5 ระดับ

หลายแหล่งจำสองอันนี้ผสมกันจนเป็น “5 ระดับ” รวด ซึ่งผิด ตอนสอบ exam ต้องตอบให้ตรงชุด

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

1) Review the Document — เช็คตัวเอกสาร BCP#

2) Review Applications Covered#

ตรวจว่า ทุก critical application ถูกครอบใน plan — ไม่ใช่แค่ server-based application หลัก แต่รวม workstation-based + niche application ที่ business พึ่ง

จุดที่ exam ออก: recovery site ต้องมี software version ที่ตรงกับ production — ถ้า version mismatch ก็ recover ไม่ได้ แม้ hardware พร้อม

3) Review BC Teams — คนพร้อมจริงมั้ย#

จุดนี้เป็น “live test” ที่ผู้สอบบัญชีทำได้ครับ:

• ขอ manifest ของแต่ละ recovery team — ใครอยู่ทีมไหน, role อะไร
• ขอ copy สัญญา / agreement กับ backup facility (hot site, vendor)
• review list ของ emergency contact (vendor, hot-site contact, key personnel) ว่า up to date มั้ย
• call sample จาก list — โทรไปจริงๆ ดูว่าเบอร์ใช้ได้ + คนยังอยู่ + มี copy ของ BCP manual

ที่เด็ดที่สุดในนี้คือ “call sample” — เป็น easy finding ที่ผ่านง่ายมากถ้าทำ แต่ส่วนใหญ่องค์กรเหมาว่า list ยังถูก ไม่เคย verify จริง

4) Plan Testing — auditor เช็คอะไรในผล test#

5) Questions to Consider — exam-relevant audit questions#

CRM ให้ list ของคำถามไว้ 20+ ข้อ ขอเลือก 8-10 ข้อที่ใกล้ exam ที่สุดมาไว้ตรงนี้:

กฎเหล็กของ auditor: ถ้าตอบ “ไม่รู้” หรือ “ต้องไปถาม” สำหรับคำถามใดคำถามหนึ่ง นั่นคือ finding ในตัวมันเองเลยครับ

กรณีจริงที่ 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#

เรื่องที่ลึกกว่านี้อ่านได้ที่#

ตอนนี้สรุปแก่นของ BCP / DRP ในมุมที่ exam D4 ออกถาม แต่บางเรื่องผมแยกไปเล่าลึกในซีรีส์ cybersecurity (บริบทกว้างกว่า audit) เผื่ออยากตามต่อ:

• IRP (Incident Response Plan / แผนตอบสนองเหตุการณ์) / NIST (National Institute of Standards and Technology — สถาบันมาตรฐานของสหรัฐ) 800-61 incident response deep dive → cybersec EP.46 (Incident Response) + cisa-d5-51 (Monitoring & IR)
• BCM (Business Continuity Management / การบริหารความต่อเนื่องของธุรกิจ) standards landscape (ISO 22301 — มาตรฐานสากล BCM, BCI — Business Continuity Institute, DRII — Disaster Recovery Institute International, FFIEC — Federal Financial Institutions Examination Council, FEMA — Federal Emergency Management Agency) — frameworks ของวงการ BCM ทั้ง landscape → cybersec EP.08 (Frameworks)
• NIST 800-34 plan family (COOP — Continuity of Operations Plan, ISCP — Information System Contingency Plan, CIP — Critical Infrastructure Protection, OEP — Occupant Emergency Plan — plan ย่อยภายใต้ BCP umbrella) → cybersec EP.46 (Incident Response)
• Insurance 7 CRM types (property, business interruption, cyber liability, E&O, valuable papers, extra expense, fidelity) → cisa-d5-43 (Policies & Physical)