1. Inherent Risk — ความเสี่ยงตามธรรมชาติ#

Inherent Risk คือระดับความเสี่ยงของกระบวนการ/หน่วยงานที่กำลังถูก audit โดยไม่คิดถึง controls

ถ้าสมมติว่าไม่มี internal control อะไรเลย กระบวนการนี้มีโอกาสเกิดปัญหาแค่ไหน?

Inherent Risk ขึ้นกับ ธรรมชาติของธุรกิจ เอง:

• บริษัทจัดการเงินสดจำนวนมาก → inherent risk สูงกว่าบริษัททำซอฟต์แวร์
• ระบบประมวลธุรกรรมล้านรายการ/วัน → สูงกว่าระบบใช้เดือนละครั้ง
• กระบวนการที่ใช้วิจารณญาณคน → สูงกว่ากระบวนการอัตโนมัติตรงๆ

ที่สำคัญ IS auditor “ลด” Inherent Risk ไม่ได้ มันเป็นลักษณะเฉพาะของกระบวนการ สิ่งที่ทำได้คือ รับรู้ ว่ามันสูงหรือต่ำ แล้วปรับความเข้มข้นของการ audit ตามนั้น

2. Control Risk — ความเสี่ยงที่ Internal Control จะล้มเหลว#

Control Risk คือความเสี่ยงที่ material error จะเกิดและ ไม่ถูกป้องกันหรือตรวจจับได้ทันเวลา โดย internal control ที่มีอยู่

นี่คือความเสี่ยงแนวที่ว่า “controls มีอยู่ แต่ไม่ทำงาน” หรือ “มีช่องโหว่”

ตัวอย่าง:

• Control risk สูง ตรวจ computer logs ด้วยมือ คนตรวจมักพลาดความผิดปกติ
• Control risk ต่ำ ตรวจสอบข้อมูลแบบอัตโนมัติที่ตั้งค่าถูกต้อง ทุกธุรกรรมผ่านการตรวจเหมือนกัน

ต่างจาก Inherent Risk ตรงที่ Control Risk เป็นลักษณะของ control system ที่ management ออกแบบ ไม่ใช่ลักษณะของกระบวนการธุรกิจเอง

3. Detection Risk / Overall Audit Risk — ความเสี่ยงที่ Auditor จะพลาด#

Detection Risk หรือ Overall Audit Risk คือความเสี่ยงที่ IS auditor จะ ไม่ตรวจจับ material error

นี่คือ risk ที่ตรงที่สุดสำหรับ IS auditor เพราะมันคือความเสี่ยงว่าความเห็นจาก audit จะ ผิด

เป้าหมายของแนวทาง audit คือคุม overall audit risk ให้อยู่ในระดับที่ “ต่ำเพียงพอ” เมื่อ audit เสร็จ

ความสัมพันธ์ระหว่าง 3 องค์ประกอบ#

ตรรกะการใช้ 3 องค์ประกอบ:

• Inherent สูง + Control สูง → ต้องทุ่ม audit effort มากกว่า
• Inherent ต่ำ + Control ต่ำ → audit ที่เบากว่าก็บรรลุ overall risk ในระดับที่ยอมรับได้

กฎผกผันที่ออกข้อสอบบ่อย#

ความสัมพันธ์ผกผันระหว่าง Materiality กับ Acceptable Audit Risk:

ยิ่ง Materiality สูง → ยิ่งรับ audit risk ได้น้อย ยิ่ง Materiality ต่ำ → ยิ่งรับ audit risk ได้มากขึ้น

ทำไม? ก็เพราะถ้าพื้นที่ที่ audit มี materiality สูง พลาดไปผลกระทบใหญ่ ก็ต้อง audit ระมัดระวังกว่า ลด audit risk ให้ต่ำ

ถ้าพื้นที่ materiality ต่ำ พลาดผลกระทบน้อย รับ audit risk สูงขึ้นได้

ผลรวมของจุดอ่อน#

จุดอ่อน internal control บางอย่างที่ดูเล็ก อาจรวมกับความเสี่ยงอื่นๆ จนกลายเป็น material ต่อระบบโดยรวมได้

เช่น ระบบไม่จับ error เล็กรายการเดียว แต่ถ้า error เกิดซ้ำในทุกธุรกรรมของวัน ผลสะสมอาจ material มาก

สองสิ่งที่ Controls ต้องตอบ#

Controls ที่ดีต้องตอบ 2 คำถาม:

1. What should be achieved controls ต้องช่วยให้บรรลุวัตถุประสงค์
2. What should be prevented controls ต้องกันการกระทำที่ไม่ต้องการ

ทั้งสองมิตินี้ต้องอยู่ในระบบ control เสมอ control ที่ป้องกันเฉยๆ โดยไม่เอื้อให้ทำงานได้ก็เป็นปัญหา เพราะกลายเป็นอุปสรรคทางธุรกิจไปซะอย่างนั้น

Control Activities เกิดทุกระดับ#

Control activities ไม่ได้เกิดแค่ที่ IT department แต่ทั่วทั้งองค์กร:

• การให้การอนุมัติและการมอบอำนาจ
• การตรวจสอบและกระทบยอด
• การทบทวนผลการดำเนินงาน
• การปกป้องทรัพย์สิน
• การทำให้เกิด separation of duties

Managerial (Administrative) Controls#

Managerial Controls คือ controls ที่เกี่ยวกับการกำกับดูแล การรายงาน ขั้นตอนปฏิบัติ และการดำเนินงานของ process

ลักษณะเฉพาะคือ ไม่ใช้ technology หรือสิ่งกีดขวางทางกายภาพ ใช้ organizational processes + การตัดสินใจของมนุษย์ เป็นกลไก

ตัวอย่าง:

• Policies and procedures เอกสารระบุว่าควรทำอะไรยังไง
• Accounting controls เช่น balancing ตรวจความถูกต้องผ่านการทบทวนโดยคน
• Compliance and development controls กระบวนการที่ทำให้กิจกรรมเป็นไปตามข้อกำหนด

Managerial controls คือ กระดูกสันหลัง ของ control system ทั้งหมด เพราะ Technical และ Physical ต้องอาศัย Managerial ถึงจะทำงานได้ถูกต้อง

Technical (Logical) Controls#

Technical Controls คือ controls ที่ใช้ technology, equipment หรือ devices

อีกชื่อในบริบท CISA คือ Logical Controls

ตัวอย่าง:

• Firewall ruleset กำหนด traffic ที่อนุญาต/ปฏิเสธ
• Antivirus software สแกน malicious code
• Intrusion Detection Systems (IDS) เฝ้าระวังและแจ้งเตือน
• Encryption ปกป้องข้อมูล at-rest และ in-transit

กฎสำคัญ: Technical ต้องอาศัย Managerial#

นี่คือจุดที่ CISA ออกข้อสอบบ่อย ลองนึก scenario คลาสสิคของวงการ

โรงพยาบาลแห่งหนึ่งซื้อระบบ encryption ราคาหลายล้านมาปกป้องข้อมูลคนไข้ ทุกอย่าง deploy ครบ encryption เปิด log เปิดครบ

หกเดือนผ่านไป auditor เดินเข้าไปถามคำถามง่ายๆ ว่า “ใครเป็นคนถือ encryption key?” คำตอบคือ “ฝ่าย IT ทุกคนเข้าได้เพราะใส่ไว้ใน shared drive ตอน deploy”

ถามอีกว่า “ถ้าวันนี้พนักงาน IT ลาออก keys ถูกเปลี่ยนทันทีมั้ย?” คำตอบคือ “ไม่เคยทำเลย”

ถามอีกว่า “ถ้า log แจ้งว่ามีการเข้าถึงข้อมูลผิดปกติ ใครเป็นคนรับ?” คำตอบคือ “เปิด alert ไว้ แต่ไม่มีใคร assign ให้ดู”

นั่นแหละสภาพของ Technical control ที่ขาด Managerial เครื่องมือทำงานได้ แต่ คนไม่ได้บริหารเครื่องมือ ผลคือ:

• key ที่ควรปกป้องข้อมูล กลายเป็นข้อมูลสาธารณะในแผนก
• ถ้ามีการรั่วของข้อมูลจริงๆ ไม่มีใครรู้ทัน เพราะไม่มีคนดู alert
• พนักงานที่ลาออกยังถือ access อยู่หลายเดือนหลังจากนั้น

ผมเรียกแบบนี้ว่า “ความปลอดภัยจอมปลอม” ครับ ผู้บริหารเชื่อว่ามี security แล้วเพราะเสียเงินซื้อมาแพง ทั้งที่กลไกบริหารเครื่องมือไม่มีอยู่จริง อันตรายกว่าตอนรู้ตัวว่าไม่มี security เพราะอย่างน้อยรู้ตัวก็ระวังตัวได้

Managerial control ที่ขาดไปในเคสนี้คือ key management policy, leaver process, alert assignment matrix เรื่องที่ดูธรรมดาแต่เป็น “กระดูกสันหลัง” ที่ทำให้ technical investment คืนทุนได้

กฎที่ต้องจำ ลงทุน Technical control เป็นล้านโดยไม่มี Managerial control รองรับ ก็คือลงทุนเสียเปล่า แถมอันตรายกว่าไม่ลงทุนเพราะคิดว่าตัวเองปลอดภัย

Physical Controls#

Physical Controls คือ controls ที่จำกัดการเข้าถึงสถานที่หรือ hardware ด้วยวิธีทางกายภาพ

ตัวอย่าง:

• Surveillance solutions cameras, motion sensors
• CCTV เฝ้าระวังและบันทึก
• Administration controls security guards, visitor logs, access badges

Physical controls ต้องการการบำรุงรักษา + เฝ้าระวัง + ความสามารถตอบสนอง alerts ไม่ใช่แค่ติดตั้งแล้วจบครับ

ทำไมต้องมีทั้งสาม?#

• มีแต่ Technical ไม่มี Physical → คนเดินเข้าถึง server โดยตรงได้
• มีแต่ Physical ไม่มี Technical → การเข้าถึง network ไม่จำกัด
• มีแต่ Managerial → นโยบายอยู่บนกระดาษไม่มีกลไกบังคับใช้

Preventive Controls — หยุดก่อนเกิด#

Preventive คือป้องกันไม่ให้ threat event เกิดตั้งแต่แรก

ตัวอย่าง Encryption, User authentication, Vault construction doors

เป็นประเภทที่ แข็งแกร่งที่สุด ในการลดความเสี่ยง

Deterrent Controls — ลด Likelihood ก่อนเกิด#

Deterrent คือยับยั้ง ไม่ได้หยุดโดยตรง แต่ทำให้ threat actor คิดหนักก่อนลงมือ

ตัวอย่าง Warning banners บน login screen, Visible cameras, Rewards for arrest of hackers

ต่างจาก Preventive ตรงที่ Deterrent ไม่ได้หยุด ทางกายภาพ แต่ ลดแรงจูงใจ ของ threat actor

Detective Controls — รู้เมื่อเกิดแล้ว#

Detective คือให้คำเตือน/ข้อมูลเกี่ยวกับ event เมื่อมันเกิดขึ้นแล้ว โดยไม่ได้ยับยั้ง

ตัวอย่าง Audit trails, IDS, Checksums

Detective ไม่ได้ป้องกัน แต่ทำให้องค์กร รู้ว่ามันเกิด เพื่อตอบสนองได้

⭐ IDS Trap: Detective ไม่ใช่ Preventive#

นี่คือกับดักข้อสอบที่ออกบ่อยที่สุดใน CISA เรื่อง control classifications

Intrusion Detection System (IDS) ฟังชื่อแล้วอาจคิดว่าเป็น preventive แต่ตามนิยามของ ISACA IDS คือ Detective Control

ทำไม? ก็เพราะ IDS ไม่ได้หยุด การบุกรุก มัน ตรวจจับและแจ้งเตือน เท่านั้น

เปรียบเทียบ:

• Firewall Preventive (บล็อก traffic ก่อนเข้า)
• IDS Detective (ตรวจจับ traffic ผิดปกติและแจ้ง)
• IPS (Intrusion Prevention System) Preventive (บล็อก traffic ที่ตรวจพบ)

Corrective Controls — แก้ไขหลังเกิด#

Corrective คือเยียวยาข้อผิดพลาด/การละเลย/การบุกรุก หลังจากที่ตรวจจับได้แล้ว

ตัวอย่าง Data backups, Error correction procedures, Incident response procedures

ทำงาน after threat event เกิดและหลัง detective controls ตรวจพบ

Compensating Controls — ทดแทนเมื่อ Primary Control ทำไม่ได้#

Compensating คือชดเชยจุดอ่อนหรือข้อบกพร่อง มักเกิดเมื่อ baseline controls ทำไม่ได้เพราะข้อจำกัดทางเทคนิค/ธุรกิจที่ชอบธรรม

ตัวอย่าง:

• วางระบบที่ไม่ปลอดภัยไว้บน isolated network segment ที่มี perimeter security แข็งแกร่ง
• เพิ่ม third-party challenge-response mechanisms สำหรับอุปกรณ์ที่ไม่รองรับ digital login

ที่สำคัญ Compensating control ต้องบรรลุ ผลลัพธ์เดียวกัน กับ control ที่ออกแบบมาเดิม ไม่ใช่แค่ “มีบางอย่างอยู่”

ตารางสรุป 5 Classifications#

IS Auditor ต้องทำอะไรกับ Link นี้?#

เวลา IS auditor ประเมิน controls:

1. ตรวจว่า controls โยงกลับไปถึง risk ที่เกี่ยวข้อง management ระบุ controls ที่สอดคล้องกับ risk แล้วรึยัง
2. ประเมินนัยสำคัญของ control weaknesses ถ้า control ไม่ทำงาน มีผลต่อ overall audit risk มั้ย?
3. ประเมินความเพียงพอ controls ที่มี ลด risk ถึงระดับที่ยอมรับได้แล้วรึยัง?

ความรับผิดชอบของ Management ต้องดูแลให้ controls ถูกบันทึกและวางตาม risk assessment ของตัวเอง

บทบาทของ IS auditor ประเมินอย่างอิสระและรายงานว่า controls นั้นได้ผลรึเปล่า

เมื่อ Controls ไม่พอ#

ถ้า controls ลด risk ลงไปถึงระดับที่ยอมรับไม่ได้ ต้องวาง controls เพิ่มเติม

ถ้าวาง controls ที่เหมาะสมไม่ได้เพราะข้อจำกัด Compensating Controls อาจเป็นทางออก แต่ต้องบรรลุผลลัพธ์เดียวกันกับ control ที่ออกแบบมาเดิม

เมื่อ Control พังจน Fraud เกิด — ประเด็น Whistleblower#

Internal control ไม่มีระบบไหนรับประกัน 100% เคสที่ปรากฏบ่อยที่สุดเวลา control พังคือ fraud ซึ่งอาจมาจาก vulnerability ของระบบ การ override โดย management หรือ collusion ของพนักงานหลายคน

ข้อหนึ่งที่ ISACA เน้นซึ่งคนมักลืม คือเรื่อง whistleblower เวลาเจอหรือสงสัยว่ามี fraud เกิดขึ้น คนที่กล้าออกมาแจ้ง (whistleblower) ก็เผชิญ risk ของตัวเองด้วย — ทั้ง retaliation จากคนถูกกล่าวหา การถูกเปิดเผยตัวตน หรือผลกระทบต่อหน้าที่การงานในระยะยาว

IS auditor และ management จึงต้องตระหนักว่า การแจ้งเหตุภายใน (complaining / whistleblowing) มี downside ต่อผู้แจ้งเสมอ การจัดการเคส fraud จึงต้องทำอย่าง discreet ตาม policy และข้อกำหนดทางกฎหมายที่เกี่ยวข้อง รวมถึงดูแล confidentiality ของ whistleblower เป็นพิเศษ ไม่ใช่แค่จัดการตัวเคสแล้วจบ

นี่คือเหตุผลที่หลายองค์กรมี whistleblower channel แยก (hotline หรือกล่องรับเรื่องที่บริหารโดยภายนอก) และมีนโยบาย anti-retaliation เขียนไว้ชัด — เพราะถ้าคนกลัวที่จะแจ้ง control failure ตัวที่ใหญ่ที่สุดก็จะไม่มีใครเห็นมัน

สำหรับ guidance เพิ่มเติม CRM อ้างถึง Standard 1207 Irregularities and Illegal Acts และ Guideline 2207

ตัวอย่าง Prescriptive Frameworks ที่ CISA ต้องรู้จัก#

ใช้ Prescriptive Framework ยังไงให้ถูกต้อง#

1. ระบุมาตรการรับมือเพิ่มเติม Framework ให้แค่ baseline แต่องค์กรอาจมี risk เฉพาะที่ framework ไม่ครอบคลุม ต้องระบุและวาง controls เพิ่มเติม

2. ระบุ controls ที่ไม่ applicable บาง prescribed controls อาจไม่เกี่ยวข้องเลย

ตัวอย่าง องค์กรรับบัตรเครดิตแต่ไม่ได้ store credit card data → controls ใน PCI DSS ที่เกี่ยวกับ “storing credit card data” ก็ไม่ apply

3. บันทึกเหตุผลของ non-applicability ถ้าตัดสินใจว่า control ไม่ apply ต้องบันทึกว่าทำไม IS auditor จะมาตรวจเหตุผลนั้น

Prescriptive vs Risk-Based: ต่างกันอย่างไร?#

ในทางปฏิบัติ หลายองค์กรใช้ ทั้งสองแบบ prescriptive เป็น baseline (compliance) และ risk-based สำหรับพื้นที่ที่ prescriptive ครอบคลุมไม่พอ