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 — รู้ว่ามีอะไรเสี่ยง#

ระบุ risk ที่อาจกระทบองค์กร — รวมถึง:

• Threat — ภัยจากภายนอก/ภายใน (hacker, insider, ภัยธรรมชาติ)
• Vulnerability — ช่องโหว่ของระบบเอง (unpatched software, weak password)
• Impact — ผลกระทบถ้าเกิด (เงินหาย, ลูกค้าหาย, regulator fine)

สูตรคลาสสิก: Risk = Threat × Vulnerability × Impact

(Modern frameworks เพิ่ม velocity เข้าไปด้วย — ความเร็วที่ risk จะกระทบ — เช่น zero-day exploit ที่กระจายเร็วเป็นชั่วโมง)

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

ขั้น 2: Risk Assessment — จัดอันดับ#

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

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

วิธีประเมินมี 3 แบบ:

Qualitative (ใช้ระดับ “high/medium/low”) — เร็ว, ใช้ความเห็น, เหมาะกับ screening Semiquantitative (ระดับ + แมป number scale) — กลางๆ Quantitative (ใช้ตัวเลข + เงิน) — แม่นยำ, ใช้ข้อมูลจริง, ทำยาก, เหมาะกับ BIA หรือ SOX

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

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

มี 4 options (จำให้ขึ้นใจ):

Avoid — เลี่ยง: ไม่ทำกิจกรรมนั้นเลย

• ตัวอย่าง: ไม่เก็บข้อมูล credit card ใน database — outsource ให้ payment gateway แทน → avoid PCI DSS scope

Mitigate — ลด: เพิ่ม control เพื่อลด likelihood หรือ impact

• ตัวอย่าง: เพิ่ม MFA + encryption + monitoring → ลด likelihood ของ data breach

Transfer / Share — โอนความเสี่ยง: ส่วนหนึ่งไปยังบุคคลที่สาม

• ตัวอย่าง: ซื้อ cyber insurance, outsource ให้ service provider — แต่ accountability ไม่ transfer (เดี๋ยวตอน 19 จะลงรายละเอียด)

Accept — ยอมรับ: ปล่อยไว้ตามนั้น เพราะ cost ของ control สูงกว่า impact

• ต้อง document ว่ายอมรับด้วยเหตุผลอะไร — accept ที่ไม่ document = เหมือน neglect

Trap คลาสสิก: “เรา accept risk นี้” โดยไม่มีเอกสาร — auditor เจอตัวนี้ flag เป็น control gap ทันที accept ที่ไม่ documented = สำหรับ auditor มองไม่ออกว่าใครตัดสินใจ ตัดสินใจเมื่อไหร่ ตัดสินใจด้วยข้อมูลอะไร

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

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

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

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

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

Pattern ที่เจอ#

หลายบริษัทคิดว่า “Privacy compliance = post privacy notice บนเว็บ” — ผิดครับ

นั่นเป็นแค่ outward-facing piece ของ program ใหญ่ที่ต้องครอบคลุม:

• People — ใครรับผิดชอบ data privacy (DPO ในกรณี GDPR)
• Process — ขั้นตอนรับ + ตอบ data subject request
• Technology — ระบบที่ implement การ delete, export, mask ข้อมูล
• Documentation — PIA, DPIA, data inventory, breach register
• Training — พนักงานรู้และมีหลักฐานว่าได้รับการอบรม

Privacy Notice vs Privacy Policy#

นี่คือคู่ที่คนใช้สลับกันบ่อย:

Privacy Notice — เอกสาร ภายนอก ที่บอก data subject ว่าบริษัทจะเก็บอะไร, ใช้ทำไม, แชร์กับใคร Privacy Policy — เอกสาร ภายใน ที่กำหนดว่าพนักงานจัดการ personal data ยังไง

ทั้งสองต้อง consistent — Notice บอกว่า “ไม่แชร์ข้อมูลกับ third party” แต่ Policy บอกว่า “แชร์ได้กับ partner ภายใต้ NDA” → contradiction → legal violation

Personal Information Inventory — รากของทุกอย่าง#

คุณปกป้องสิ่งที่คุณไม่รู้ว่าตัวเองมีไม่ได้

หลายบริษัทรู้คร่าว ๆ ว่ามี personal data อยู่ใน CRM, ERP, HR system — แต่ไม่รู้ว่ามีอยู่ที่ไหนอีกบ้าง: backup tape เก่า, Excel ใน laptop พนักงาน, log file ที่บันทึก IP address

Personal Information Inventory = เอกสารที่ map ทุกที่ ที่ personal data อยู่ พร้อม:

• ประเภท data
• วัตถุประสงค์การเก็บ
• legal basis (consent, contract, legitimate interest)
• ที่เก็บ
• ใครเข้าถึงได้
• ระยะเวลาเก็บ

ถ้าไม่มี inventory — ตอน data breach บริษัทตอบ regulator ไม่ได้ว่า “ข้อมูลใครถูกกระทบ” → fine สูง

PIA / DPIA#

PIA (Privacy Impact Assessment) / DPIA (Data Protection Impact Assessment) — การประเมินผลกระทบ privacy ก่อน launch ระบบใหม่หรือ process ใหม่

หัวใจ: proactive ไม่ใช่ reactive — ทำก่อนที่ระบบจะ live ไม่ใช่ทำหลังจาก breach

เดี๋ยว Domain 5 จะลงเทคนิค privacy controls (encryption, masking, access control, DLP) — ตอนนี้รู้แค่ว่า privacy program คือ governance framework ที่ทำให้ technical controls ใน D5 มีที่อยู่

Privacy Audit#

IS auditor มี role โดยเฉพาะในการตรวจ privacy:

• Vendor contract มี data privacy clauses มั้ย
• การ implement data retention + destruction ตรงตาม policy มั้ย
• Cross-border data transfer ผ่าน legal mechanism ที่ถูกต้องมั้ย
• พนักงานได้รับการอบรม + มีหลักฐานมั้ย
• Data inventory ทันสมัย
• Data subject request ถูก handle ตามกรอบเวลากฎหมายมั้ย

Data Classification — ก่อนทุกอย่าง#

คุณปกป้อง data ทุกชิ้นเหมือนกันไม่ได้ — ทำได้แต่ไม่คุ้มและไม่มีประสิทธิภาพ

Data classification = แบ่ง data ตาม sensitivity เพื่อ apply control ที่เหมาะสม

ระดับมาตรฐาน (4 ระดับ):

(บางบริษัทใช้ 3 ระดับ บางบริษัท 5 — concept เดียวกัน)

ลองเทียบกับระบบเอกสารราชการไทยที่เราคุ้น — ปกติ / ลับ / ลับมาก / ลับที่สุด — concept เดียวกัน

Data Owner vs Data Custodian — Trap ที่กลับมา#

เราคุยกันใน ตอน 16 ไปแล้วในส่วน SoD — ในนี้จะลงรายละเอียดเพิ่ม

Data Owner = business manager ที่รับผิดชอบ data

• เป็นคน classify data
• เป็นคน อนุมัติ access
• เป็นคน define retention period
• ตัวอย่าง: หัวหน้าฝ่ายขาย เป็น data owner ของ customer data
• หัวหน้าฝ่าย HR เป็น data owner ของ employee data

Data Custodian = IT staff ที่ เก็บและปกป้อง data ตามคำสั่ง owner

• DBA, system admin, cloud admin
• ไม่มีอำนาจตัดสิน — แค่ implement
• ไม่ classify data — แค่ tag ตามที่ owner กำหนด

Trap คลาสสิก: Developer เข้าถึง Production Data#

หนึ่งใน scenario ที่ออกข้อสอบ ISACA บ่อยที่สุด:

Scenario: บริษัท software house — developer ขอ access production database เพื่อ debug ปัญหาที่เกิดเฉพาะใน production — ผู้จัดการ IT บอก “เร่งด่วน อนุมัติให้ก่อน”

คำถาม: auditor มองว่าเป็นปัญหา?

คำตอบ: ใช่ — มี 2 ปัญหา:

1. SoD violation — developer ไม่ควรเข้า production data เพราะ developer = build, ไม่ใช่ run/operate
2. Authorization violation — IT manager ไม่ใช่ data owner ผู้อนุมัติต้องเป็น data owner (ฝั่ง business)

วิธีที่ถูก: ใช้ anonymized / masked data ใน test environment — developer debug ได้โดยไม่ต้อง access production

Data Subject Rights#

ภายใต้ PDPA + GDPR data subject (ลูกค้า/พนักงาน) มีสิทธิ์:

• Right to access — ขอดูว่าบริษัทมี data ของตัวเองอะไรบ้าง
• Right to correction — ขอแก้ข้อมูลที่ผิด
• Right to deletion / be forgotten — ขอลบ
• Right to data portability — ขอ export ในรูป machine-readable
• Right to object — ปฏิเสธการประมวลผลบางประเภท

บริษัทต้องมี process + register สำหรับ request เหล่านี้ — มี timeline ที่กฎหมายกำหนด (PDPA = 30 วัน)

เดี๋ยว Domain 5 จะใช้ data classification เป็น input ของ access control design ในระดับ technical — ตอนนี้รู้แค่ว่า classification คือรากที่ทำให้ access control + encryption + DLP มี criteria ทำงาน