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 ที่ผมเจอจริงในงาน consulting

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

หกเดือนผ่านไป ผมไปเยี่ยมและถามคำถามง่ายๆ — “ใครเป็นคนถือ 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 ที่ออกแบบมาเดิม

ตัวอย่าง 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 ครอบคลุมไม่พอ