ERM คืออะไร?#

Enterprise Risk Management (ERM) = การจัดการความเสี่ยงทั่วทั้งองค์กรแบบมีระบบ ไม่ใช่ปล่อยให้แต่ละแผนกบริหารความเสี่ยงของตัวเองแยกกัน

ในมุม IT มักเรียก ISRM (Information Security Risk Management) เป็น subset ของ ERM ที่เจาะจงเรื่อง information + IT

นิยามที่ ISACA เน้น:

ISRM = management function ไม่ใช่ audit function

นี่คือเส้นที่ห้ามข้ามครับ management เป็นคนทำ risk management ส่วน auditor ประเมินว่า management ทำดีมั้ย

ถ้า auditor กระโดดเข้าไป run ISRM เอง = independence หาย → ตรวจตัวเองในรอบหน้าไม่ได้

Risk Appetite vs Risk Tolerance#

คู่นี้ออกข้อสอบบ่อยมากครับ:

Risk Appetite — ระดับ + ประเภทของความเสี่ยงที่ องค์กรโดยรวม ยอมรับเพื่อบรรลุเป้าหมาย

ตัวอย่าง: บริษัท startup อาจมี risk appetite สูงในเรื่องการลอง technology ใหม่ — เพราะการ innovate เป็นจุดเด่น

Risk Tolerance — ระดับเบี่ยงเบนจาก risk appetite ที่ยอมรับได้สำหรับ risk category เฉพาะ

ตัวอย่าง: startup เดียวกัน อาจมี risk appetite สูงสำหรับ “technology innovation” — แต่ risk tolerance ต่ำมากสำหรับ “data breach”

ลองเปรียบเทียบกับคนขับรถ:

• Appetite — โดยรวม “ฉันชอบขับเร็ว”
• Tolerance — เฉพาะ “บนทางหลวงไม่เกิน 120 km/h, ในเมืองไม่เกิน 60”

Trap: หลายคนใช้สลับกัน แต่ ISACA เน้นว่า appetite = strategic (ระดับองค์กร) tolerance = operational variance (ระดับเฉพาะ category)

กฎ: ทั้ง 2 ต้องถูก Document#

Risk appetite + tolerance ที่ board ไม่ approve เป็นทางการ = pretend governance ผู้จัดการแต่ละคนจะตั้ง threshold ของตัวเอง → inconsistent ทั้งบริษัท

IS auditor มองหาเอกสาร Risk Appetite Statement ที่ board approve

ขั้น 1: Risk Identification — รู้ว่ามีอะไรเสี่ยง#

ระบุ information assets ที่ต้องปกป้อง + ระบุ threats + vulnerabilities

Asset categories ที่ต้องคิดถึง (ตาม CRM):

• Information และ data
• Hardware
• Software
• Documents
• Personnel
• Clients และ customers
• Buildings, inventory, cash, intangibles (goodwill, reputation)

Risk = Threat × Vulnerability × Impact (× Velocity ใน modern frameworks)

velocity = ความเร็วที่ risk กระทบ — เช่น zero-day exploit ที่กระจายเร็วเป็นชั่วโมง vs slow-moving regulatory change ที่มีเวลา 2 ปี

Trap: confuse threat กับ vulnerability — threat = คน/สิ่งภายนอกที่อาจทำร้าย vulnerability = ช่องโหว่ของเราที่เปิดให้ทำได้ ทั้งสองต้องมาประกอบกันถึงจะเกิด risk

ขั้น 2: Risk Assessment — จัดอันดับ + ระบุ Threat/Vulnerability ละเอียด#

ประเมินแต่ละ risk ใน 2 มิติ:

• Likelihood (ความน่าจะเกิด)
• Impact (ผลกระทบถ้าเกิด)

จะลงลึกของขั้นนี้ในส่วนที่ 3

ขั้น 3: Risk Response — ทำอะไรกับ Risk#

มี 4 options (จะลงรายละเอียดในส่วนที่ 4)

ขั้น 4: Risk Monitoring — วงจรปิดวง#

หลัง response แล้ว ต้อง monitor ว่า:

• Control ทำงานจริงตามที่ออกแบบมั้ย
• Risk environment เปลี่ยนหรือยัง (threat ใหม่, vulnerability ใหม่)
• Residual risk (risk ที่เหลือหลัง control) ยังอยู่ในระดับ appetite มั้ย

Monitoring + Reporting ขั้นนี้รวม 3 activity:

1. Risk assessment update — เห็น signal ว่า risk landscape เปลี่ยน → ประเมินใหม่
2. Risk mitigation — control ที่ทำอยู่ยังเพียงพอมั้ย ต้อง upgrade ไหม
3. Risk evaluation — ระดับ residual risk ที่บริษัทรับ ยังอยู่ใน management’s appetite มั้ย

→ ผลของ monitoring ป้อนกลับเข้า identification ของรอบหน้า → วงจรปิด

ถ้าหยุดที่ขั้น 3 ไม่ทำขั้น 4 = “ไปหาหมอครั้งเดียวแล้วลืมทุกอย่าง” risk landscape เปลี่ยนแล้วบริษัทไม่รู้ตัว

Common Classes of Threats#

CRM แบ่ง threats ที่ enterprise เจอเป็น 5 classes ใหญ่:

• Errors and omissions — พนักงานทำผิดโดยไม่ตั้งใจ (กดผิด, configuration ผิด)
• Malicious damage / attack — โจมตีตั้งใจ
• Fraud — ทุจริต (ส่วนใหญ่ insider)
• Theft — ขโมย (data, hardware, IP)
• Equipment / software failure — ระบบล้ม

Threat Actors — ใครเป็นภัย#

ในมุม malicious threats — CRM ระบุ threat actor types ที่ exam ออกบ่อย:

• Novices (script kiddies) — มือใหม่ที่ใช้ tools ของคนอื่น แรงจูงใจ = อยากดัง / curiosity
• Hacktivists — โจมตีเพื่อ political message หรือ ideology
• Criminals — โจมตีเพื่อเงิน (ransomware, fraud, identity theft)
• Terrorists — โจมตีเพื่อสร้าง chaos / political agenda
• Nation-states — รัฐบาลโจมตีรัฐอื่น (espionage, infrastructure disruption)
• Riots and civil unrest — กลุ่มคนที่กระทบ infrastructure
• Political instability and transitions — การเปลี่ยนระบอบที่กระทบ business

ทำไม auditor ต้องรู้ taxonomy นี้? เพราะ control design ต่างกันตาม threat type script kiddie ใช้ basic perimeter security ก็จับได้ / nation-state ต้องใช้ advanced threat hunting + zero-trust architecture

Environmental Threats — ภัยจากธรรมชาติ#

นอกจาก human threats — ยังมี environmental threats:

• Floods — อุทกภัย (น้ำท่วมปี 2554 = case study ใน Thai context)
• Lightning — ฟ้าผ่ากระทบไฟฟ้า + electronic
• Tornados / Hurricanes — พายุที่ทำลาย physical infrastructure
• Earthquakes — แผ่นดินไหว
• Fires — ไฟไหม้ data center

Environmental threats เป็น input หลักของ Business Continuity Planning (เดี๋ยว Domain 4 จะลง BCP/DRP ลึก)

Vulnerabilities — ช่องโหว่ที่ Threat Exploits#

CRM ระบุ vulnerabilities ที่เจอบ่อย:

• Lack of user knowledge — ผู้ใช้ไม่รู้ best practice
• Lack of security functionality — ระบบขาด features ที่ควรมี
• Inadequate user awareness/education — เช่น password choice แย่
• Untested technology — ใช้ tech ใหม่ที่ยังไม่ proven
• Transmission of unprotected communications — ส่งข้อมูลไม่ encrypt

หัวใจคือ threat อย่างเดียวทำอะไรไม่ได้ ถ้าไม่มี vulnerability ให้ exploit vice versa เหมือนกัน

Loss Types — ผลของ Threat × Vulnerability#

ถ้า threat agent exploit vulnerability → impact (loss) — มีหลายแบบ:

• Direct loss of money (cash, credit)
• Breach of legislation (regulatory fine)
• Loss of reputation / goodwill
• Endangerment of staff or customers (safety)
• Breach of confidence (data leak)
• Loss of business opportunity
• Reduction in operational efficiency / performance
• Interruption of business activity (downtime)

ที่น่าสังเกตคือ losses บางอย่าง quantifiable (เงิน fines) บางอย่าง qualitative (reputation, confidence) → บังคับให้ต้องใช้ risk methods หลายแบบ (qualitative + quantitative) ไม่ใช่อันเดียว

Control Matrix — Strength ของ Control#

CRM Figure 2.11 แสดง matrix ที่จัด control strength ตาม 2 มิติ:

Strength → เพิ่มขึ้นจาก Manual → IT-Dependent → Automated

ทำไม Automated > Manual?

• Manual = ขึ้นกับ human consistency (เหนื่อย, ลืม, bias)
• Automated = ทำงานเหมือนเดิมทุกครั้ง (deterministic)

ทำไม Preventive ≠ Detective ≠ Corrective?

• Preventive = ป้องกันเหตุก่อนเกิด (firewall, MFA)
• Detective = จับเหตุระหว่างเกิด (IDS, log monitoring)
• Corrective = แก้หลังเกิด (incident response, backup restore)

ที่ exam ออกบ่อย: “ระบบที่ใช้ manual review โดยพนักงานคนเดียว — auditor’s concern หลัก?” → inconsistency + บุคคล bottleneck — strength ต่ำ ควร upgrade ไป IT-dependent หรือ automated

Final Acceptance ของ Residual Risk#

CRM ระบุว่า การ accept residual risk ต้องคำนึงถึง:

• Management override — มี mechanism ให้ override ไหม
• Risk appetite — ระดับที่ board approve
• Risk identification + measurement — accuracy ของการประเมิน
• Uncertainty ใน assessment approach
• Cost + effectiveness ของ implementation
• Cost of control vs benefit ของ risk reduction

→ Risk acceptance ไม่ใช่ “ขี้เกียจ” เป็น decision ที่ต้องมี criteria + documentation

Qualitative#

ใช้ words / descriptive rankings — high / medium / low / critical

ลักษณะ:

• เร็ว, ใช้ความเห็น (subjective)
• ใช้ checklists, interviews
• เหมาะกับ screening-level analysis (ไล่ทุก risk เร็วๆ ก่อน drill down)
• ขาด rigor สำหรับ accounting / management decision ที่สำคัญ

ตัวอย่าง: “Risk ของ data breach ในระบบ HR = High” — บอกแล้วว่าสำคัญ แต่บอกไม่ได้ว่าเสียหายเท่าไหร่

Semiquantitative#

ใช้ descriptive rankings + numeric scale — เช่น high=5, medium=3, low=1

ลักษณะ:

• กลางระหว่าง qualitative + quantitative
• ลด subjectivity แต่ไม่ต้อง full data
• ใช้เมื่อ quantitative ทำไม่ได้แต่ qualitative หยาบเกินไป

Delphi Technique — เครื่องมือ semiquantitative ที่ exam ออก

• Survey แบบ structured (“On a scale of 1 to 5…”)
• Multiple expert respondents
• Iterative — ทำหลายรอบจน consensus
• ใช้เมื่อ historical data ขาด แต่ต้องการ rigor มากกว่า simple high/medium/low

Quantitative#

ใช้ numerical / monetary values — เช่น “Risk = $50,000 likelihood × 5$2,500 expected loss”

ลักษณะ:

• แม่นยำที่สุดในทางทฤษฎี
• ต้องการ data จาก historical records, industry benchmarks, statistical theory, testing
• เหมาะกับ BIA (Business Impact Analysis) + SOX compliance
• Pure quantitative ทำไม่ได้ — เพราะบาง factor (เช่น reputation) เป็น qualitative ในเนื้อแท้

Trap: ใช้ qualitative ในเรื่องที่ stakes สูงมาก (เช่น financial reporting under SOX) — methodology mismatch IS auditor flag ทันที

ในทางปฏิบัติ บริษัทที่ mature ใช้ทั้ง 3 methods ใน different contexts:

• Screening risks → Qualitative
• Mid-level decisions → Semiquantitative (Delphi)
• High-stakes financial / BIA → Quantitative