โครงของบท#

• โหมดประมวลผล 2 แบบ — batch กับ online real-time ต่างกันยังไง เลือกอันไหนเมื่อไหร่ และ audit trail หายไปไหน
• IT general controls vs application controls — กรอบใหญ่คุมทั้งบ้าน กับตัวคุมเฉพาะแต่ละ app แยกกันตรงไหน
• application controls ตาม input / processing / output — edit check, limit check, check digit, validity check, hash total อยู่ตรงไหนของสายงานข้อมูล
• Topical Requirements กับ emerging IT risk — ของใหม่ที่ The IIA ออกมาเสริม the Standards ใช้เมื่อไหร่ ใครรับผิดชอบ
• control frameworks — COSO, COBIT, ISO 27001 แต่ละอันมีลายนิ้วมือของตัวเอง จับให้ตรง

โหมดประมวลผล: รอเป็นกลุ่มได้ กับ ต้องเดี๋ยวนี้เลย#

เริ่มจากของพื้นๆ ที่สุดก่อน ระบบคอมพิวเตอร์ประมวลผลรายการได้ 2 ท่าใหญ่ๆ ลองนึกถึงร้านเถ้าแก่ที่มีงานสองแบบ

แบบแรก คิดเงินเดือนพนักงาน เดือนละครั้ง หรือทุกสองอาทิตย์ครั้ง งานแบบนี้ไม่มีใครต้องรู้ผลเดี๋ยวนั้น รวบรวมรายการทั้งกองมาประมวลทีเดียวตอนกลางคืนก็ได้สบายๆ นี่คือ batch processing สะสมรายการเป็นชุดแล้วยิงเข้าเครื่องรวดเดียว ข้อดีจริงๆ ของมันคือประหยัด ใช้คนน้อย ใช้ทรัพยากรน้อย และที่สำคัญสำหรับคนอย่างเรา คือ ตรวจง่าย เพราะมันทิ้งร่องรอยไว้เป็นชุดๆ ชัดเจน

แบบที่สอง จองที่นั่งสายการบิน หรือระบบอนุมัติวงเงินสินเชื่อตอนลูกค้ามายืนขอกู้ งานแบบนี้ต้องรู้ผลเดี๋ยวนี้ จะให้รอประมวลตอนกลางคืนไม่ได้ ฐานข้อมูลต้องอัปเดตทันทีที่กดรายการเข้าไป ระบบแบบนี้เรียก online transaction processing (OLTP) systems หรือเรียกสั้นๆ ว่า online / real-time ส่วน online controls ก็คือตัวคุมที่ทำงานตอนคนกำลังพิมพ์ข้อมูลเข้า input screen สดๆ นั่นแหละ

มุมเถ้าแก่: เลือกผิดโหมดเจ็บกระเป๋าทั้งคู่ ลองคิดดูนะ ถ้าเอา real-time ไปทำงานที่รอได้ ก็จ่ายแพงเกินจำเป็น แต่ถ้าเอา batch ไปทำงานที่ลูกค้ายืนรอคำตอบอยู่ตรงหน้า ก็เสียลูกค้า วิธีตัดสินง่ายๆ ถามตัวเองว่า ผลลัพธ์อันนี้ต้องไปมีผลกับการตัดสินใจที่กำลังเกิดตอนนี้เลยไหม ถ้าใช่ (ตอบลูกค้าเรื่องยอดเงินทันที, อนุมัติสินเชื่อ, master file ต้องสดตลอด) ก็ online/real-time แต่ถ้ารายการคล้ายๆ กัน ปริมาณเยอะ แล้วจัดกลุ่มตามตารางเวลาได้ (เงินเดือน, ปิดบัญชีแยกประเภทรายเดือน, วางบิลทีละกอง) ก็ batch

มุมผู้ตรวจ: ตรงนี้ข้อสอบชอบวางกับดักไว้เยอะมาก แล้วก็เป็น pattern ที่เจอซ้ำจนต้องจำ

⚠️ กับดัก: ข้อสอบชอบเอาข้อดีจริงๆ ของ batch (ประหยัด ใช้คนน้อย ตรวจง่าย มี audit trail เยอะ) ไปแปะเป็น “ข้อดีของ real-time” แล้วหลอกให้เลือก มันไม่ใช่ ข้อดีของ real-time ที่ระบุไว้มีอย่างเดียวคือ timeliness (ความทันเวลาของข้อมูล) จบ ส่วน accuracy กับ validation of transactions เป็นตัวหลอกที่ตัดสินไม่ได้ เพราะสองโหมดถูกต้องพอกัน แล้วก็ validate ได้ทั้งคู่ ถ้าโจทย์กลับด้านมาถามหา ข้อเสียของ batch คำตอบคือ ข้อมูลจะสดก็ต่อเมื่อ update เสร็จ มี time delay ไม่ใช่ไปตอบจุดอ่อนของ real-time

⚠️ กับดัก: อย่าไปติดกับคำ absolute ระบบเดียวใช้ทั้ง batch และ online พร้อมกันได้ ในแอปเดียวกันด้วยซ้ำ ตัวเลือกไหนที่บอกว่า “ต้องเลือกอย่างใดอย่างหนึ่ง” “เครื่องเดียวทำสองแบบไม่ได้” “ยังไงก็ต้องเลือก real-time เสมอ” หรือ “batch มันตกยุคแล้ว” — ตัดทิ้งหมด และถ้าเจอตารางเทียบคุณสมบัติแล้วถามว่าแถวไหนผิด แถวที่ผิดมักเป็นแถวที่ไปติดป้ายว่า batch เป็น interactive — เพราะความ interactive เป็นของ real-time ไม่ใช่ batch

audit trail: ร่องรอยที่ย้อนกลับไปหาต้นตอได้#

พอย้ายจากสมุดมือมาเป็นคอมพิวเตอร์ สิ่งที่หายไปแบบเงียบๆ คือร่องรอยกระดาษ เมื่อก่อนอยากรู้ว่ารายการนึงมาจากไหน ก็ไล่ใบเสร็จ ใบสั่งซื้อ สมุดบัญชี ทีละใบ แต่พอเป็นระบบคอมพิวเตอร์ ร่องรอยที่ครบถ้วนอาจอยู่แค่ชั่วครู่ หรืออยู่ในรูปที่เครื่องอ่านได้เท่านั้น

ตรงนี้แหละที่ audit trail (ร่องรอยการตรวจสอบ) เข้ามาแทน ระบบที่ออกแบบมาดีจะบันทึกทุกการกระทำของผู้ใช้ เวลาเข้าถึง การแก้ข้อมูล ใครอนุมัติอะไร พร้อม timestamp ทำให้เราย้อนลำดับเหตุการณ์กลับไปจนถึงต้นตอได้ ประเด็นคือ audit trail มันทำหน้าที่บันทึกประวัติที่ตามรอยได้ ไม่ใช่แค่คอยเตือน

⚠️ กับดัก: ข้อสอบชอบเอาฟีเจอร์อื่นมาปลอมเป็น audit trail “real-time transaction monitoring” จับความผิดปกติตอนมันเกิด แต่ไม่ได้เก็บประวัติครบ, “email alert / exception filtering” แค่ชี้จุดที่ผิดปกติ ไม่ได้บันทึกทุกกิจกรรม, “data reconciliation” หรือ “digital signature” เป็นเรื่อง consistency/integrity ไม่ใช่การ log กิจกรรม จำหลักง่ายๆ อันไหนที่แค่ detect, alert, reconcile, หรือ sign ก็ไม่ใช่ audit trail ตัว audit trail คืออันที่ record ประวัติทั้งหมดที่ย้อนกลับไปหาต้นตอได้ และถ้าถามถึง “วัตถุประสงค์หลัก” ของมัน คำตอบคือเอาไว้ตรวจสอบและสืบสวนรายการ/สนับสนุน accountability ไม่ใช่ตรวจจับ error แบบ real-time

คอมพิวเตอร์ vs มือคน: วิธีเปลี่ยน แต่เป้าหมายไม่เปลี่ยน#

เรื่องนี้ดูเป็นปรัชญา แต่ข้อสอบออกตรงๆ อยู่บ่อย พอองค์กรย้ายจากงานมือมาเป็นระบบคอมพิวเตอร์ อะไรเปลี่ยน อะไรไม่เปลี่ยน

สิ่งที่ ไม่เปลี่ยน คือหลักการและวัตถุประสงค์ของการควบคุมภายใน (internal control) เรายังต้องการความถูกต้อง ครบถ้วน มีการอนุมัติเหมือนเดิมทุกอย่าง ส่วนสิ่งที่ เปลี่ยน คือวิธีการ (methodology) ในการติดตั้งตัวคุม จากเดิมที่คนหลายคนช่วยกันตรวจตามขั้นตอน กลายมาเป็นตัวคุมฝังในโปรแกรม (embedded controls) ที่บังคับกฎเดียวกันกับทุกรายการอย่างสม่ำเสมอ แล้วรูปแบบของ audit trail ก็เปลี่ยนไปด้วย

⚠️ กับดัก: ตัวเลือกที่บอกว่า “หลักการควบคุมเปลี่ยน” “วัตถุประสงค์ต่างออกไป” หรือ “วัตถุประสงค์ยากขึ้น” ผิดหมด เพราะเปลี่ยนแค่ design กับ implementation เท่านั้น ส่วน “การทุจริต (fraud) ลดลงเพราะระบบอัตโนมัติ” ก็ผิด เพราะการรวมหน้าที่จนไม่มีการแบ่งแยกหน้าที่กลับ เพิ่ม ความเสี่ยง fraud ต่างหาก อีกจุดที่ต้องระวังคือความสม่ำเสมอมันดาบสองคม เครื่องประมวลรายการแบบเดียวกันหมด กำจัด random error ของคนได้จริง (นี่แหละคือคุณสมบัติเด่นที่แยกคอมพิวเตอร์ออกจากงานมือ) แต่พอมี bug ในโปรแกรมทีนึง มันก็ทำ ผิดเหมือนกันหมดทุกรายการ อย่างเป็นระบบ ถ้าโจทย์ถามผลของการเปลี่ยนระบบเฉพาะจุด (เช่นเปลี่ยนบัตรตอกเวลาเป็นบัตรแม่เหล็ก) คำตอบคือ ส่วนหนึ่งของ audit trail ถูกเปลี่ยนไป ไม่ใช่ “fraud ลด” หรือ “ไม่มี trail เลย”

general controls vs application controls: บ้านทั้งหลัง กับ ห้องแต่ละห้อง#

ทีนี้มาถึงแกนกลางของ IT controls ที่ข้อสอบ Part 2 ให้น้ำหนักมาก แบ่งใหญ่ๆ เป็นสองชั้น

IT general controls (ITGC) เปรียบเหมือนโครงสร้างของทั้งบ้าน คุมเรื่องที่กระทบทั้งสภาพแวดล้อม IT ทั้งองค์กร ได้แก่ การดำเนินงานศูนย์ข้อมูลและเครือข่าย, การจัดหา/พัฒนา/แก้ไข/บำรุงรักษาฮาร์ดแวร์ซอฟต์แวร์, access security (ทั้ง physical และ logical), ไปจนถึงเรื่องใหม่ๆ อย่างการคุม AI/ML และ RPA ประเด็นสำคัญคือ ต้องมั่นใจว่า general controls ทำงานดีก่อน ถึงจะไปวางใจ application controls ได้ เพราะถ้าโครงบ้านโยก ตัวคุมในห้องแต่ละห้องก็ไร้ความหมาย

Application controls เป็นตัวคุมเฉพาะของแต่ละแอป บางตัวมาพร้อมกับซอฟต์แวร์ที่ซื้อจาก vendor บางตัวต้องเขียนใส่เองตอนพัฒนา แบ่งตามช่วงของสายงานข้อมูลได้เป็น input / processing / output

มุมเถ้าแก่: อยากให้ระบบเชื่อถือได้ ต้องลงทุนที่ฐานก่อน — คนที่เข้าถึงข้อมูลได้ ใครแก้โปรแกรมได้ ใครอนุมัติ change ถ้าเรื่องพวกนี้หละหลวม ต่อให้แต่ละแอปมีตัวเช็กสวยหรูแค่ไหนก็เอาไม่อยู่

มุมผู้ตรวจ: trigger คำสำคัญที่ต้องจับคือ ตัวคุมนั้น อยู่ตรงไหนของสายงานข้อมูล และเป็นเรื่องของ ทั้งสภาพแวดล้อม หรือ แอปเดียว

⚠️ กับดัก: general vs application สลับกันบ่อย เรื่องพัฒนา/แก้ไขโปรแกรม การอนุมัติระบบใหม่ตามนโยบาย = general control (คุมทั้งสภาพแวดล้อม) ส่วน edit ต่อรายการ เช่น field check ที่คัดตัวอักษรผิดประเภทออก = application (input) control ตัวเลือกชุดเดียวกันเป๊ะ พลิกคำตอบได้ตามว่าโจทย์ถามแกนไหน

application controls: จับความผิดให้ตรงกับตัวตรวจ#

นี่คือส่วนที่ข้อสอบเล่นละเอียดที่สุด แล้วก็เป็นจุดที่คนพลาดกันเยอะ หลักคือ ดูว่าอะไรพัง แล้วเลือกตัวคุมที่ทำงานนั้นโดยเฉพาะ อย่าจำแบบท่องชื่อ

ฝั่ง input ตอนข้อมูลกำลังเข้า มีตัวช่วยหลายตัว Edit (field) checks จอรับข้อมูลกันไม่ให้พิมพ์ข้อมูลผิดประเภทเข้ามา เช่น ใส่ตัวเลขในช่องชื่อ หรือใส่ตัวอักษรในช่องจำนวนเงิน จะถูกปัดออก Limit (reasonableness) checks จำกัดค่าให้อยู่ในช่วงที่สมเหตุสมผล เช่น ชั่วโมงทำงานต้องไม่เกินที่ควร หรือใบแจ้งหนี้เกินวงเงินต้องให้หัวหน้าอนุมัติ นอกจากนี้ก็มี check digit, validity check ที่ต้องแยกให้ออก

มาดูตัวที่สับสนกันบ่อยที่สุด — validity check กับ check digit สองตัวนี้เกาะกับเลขรหัสเหมือนกัน แต่ทำงานคนละอย่าง

• Validity check ถามว่า “ค่านี้มีอยู่จริงในรายการ/ไฟล์หลักไหม” เช่น เลขลูกค้าที่ไม่มีในรายชื่อที่อนุมัติ, รหัสไปรษณีย์ที่ไม่มีจริง, ตัวย่อรัฐที่ผิด, vendor ที่ไม่มีใน master file — จับด้วย validity check
• Check digit ถามว่า “เลขนี้พิมพ์ถูกต้องไหม” คือมันคำนวณหลักตรวจสอบขึ้นมาใหม่ เพื่อจับการพิมพ์เลขสลับหลัก (transposition) หรือพิมพ์ผิด แม้ค่าที่ได้จะไม่มีอยู่จริงก็ตาม

⚠️ กับดัก: อ่านโจทย์ว่าเน้นคำว่า “ไม่มีในไฟล์” (→ validity check) หรือ “พิมพ์สลับหลัก/พิมพ์เลขผิด” (→ check digit ถ้ามีให้เลือก) ถ้าเลขถูกพิมพ์สลับหลักแต่ ไม่มี ตัวเลือก check digit ให้ใช้ validity check แทน เพราะเลขที่พิมพ์ผิดจะไปหาไม่เจอใน master file เอง และจำอีกอันที่โหด — check digit แบบ บวกผลรวมของหลัก (sum-of-digits) จะจับ transposition ไม่ได้ เพราะบวกกันแล้วผลรวมเท่าเดิม ในโจทย์แบบ “detect ได้ทุกอย่าง EXCEPT” คำตอบคือ transposition

ที่เหลือจับคู่ง่ายขึ้น — ตัวเลขใหญ่เกินช่วง (400 ชั่วโมงแทน 40, วันที่ 31 เมษายน) → limit / reasonableness check, พิมพ์ตัวอักษรผิดประเภทในช่อง (ตัว R ในช่องจำนวน) → field / format check, ช่องบังคับปล่อยว่าง → completeness test

ฝั่ง batch total มีสามยอด ทำสามงานคนละอย่าง อย่าสับ

• record count = นับว่ามีกี่รายการ/กี่เอกสาร
• financial total = ผลรวมจำนวนเงินที่มีความหมายจริง (เงินเดือนสุทธิ, ยอดขาย) ใช้จับค่าเงินที่พิมพ์สลับ เช่น 13.66 แทนที่จะเป็น 133.66
• hash total = ผลรวมของ field ที่ปกติ ไม่มีใครเอามาบวกกัน (เลขใบแจ้งหนี้, เลขพนักงาน, เลขแผนก) ผลรวมมันไม่มีความหมายในตัวเอง แต่ใช้ยืนยันความครบถ้วนได้ว่าไม่มีรายการหาย/เพิ่ม

⚠️ กับดัก: โจทย์ชอบเอาตัวเลขเงิน (financial total) หรือยอดนับเฉยๆ (record count) มาปลอมเป็น hash total — ถ้า field ที่เอามาบวกมันเป็นเงินจริงมีความหมาย มันไม่ใช่ hash total และถ้าโจทย์ถามว่าจะจับพนักงานปลอม/พนักงานถูกสวมรอยด้วยเลขพนักงานยังไง คำตอบคือ hash total ของเลขพนักงาน ไม่ใช่ยอดเงินหรือยอดนับ

ฝั่ง processing ตัวคุมทำงานตอนข้อมูลกำลังถูกอัปเดต/คำนวณ/จับคู่อยู่ในระบบ เช่น การกระทบยอดอัตโนมัติจาก payroll ไป GL, การ match รายการเข้ากับ master file แล้วส่งรายการที่ไม่ตรงไป suspense file, หรือ transaction log ที่บันทึกทุกรายการที่ประมวลผล

ฝั่ง output ตัวคุมทำงานหลังประมวลผลเสร็จ อยู่ที่ผลลัพธ์และการแจกจ่าย เช่น การกระทบผลลัพธ์กับ input, การทบทวน run log, หรือ distribution log ว่าใครได้รับรายงานบ้าง

⚠️ กับดัก: input กับ processing สลับกันบ่อยมาก ตัวคุมที่ทำงานกับข้อมูลที่ อยู่ในระบบแล้ว (update, matching, คำนวณ) = processing ไม่ใช่ input ส่วนตัวคุมที่อยู่ตอน/ก่อนป้อนข้อมูล = input ถึงแม้ชื่อจะฟังดูเหมือน processing ก็ตาม แล้ว output control ก็มักถูกแต่งตัวมาปลอมเป็น processing/input อีก จำแกนให้แน่น ก่อน/ตอนเข้า = input, ระหว่างประมวล = processing, หลังออกผล = output

access & segregation: จำกัดสิทธิ์และแยกหน้าที่ ชนะทุกอย่าง#

พอเจอโจทย์แนว “วิธีไหน ดีที่สุด” “ต้องแก้อะไร ก่อน” หรือ “ความเสี่ยง สูงสุด อยู่ตรงไหน” ในเรื่อง IT ให้มองหาคำตอบที่ไปจัดการเรื่อง ใครเข้าถึงหรือแก้อะไรได้ ก่อนเสมอ ก็คือ role-based access control (RBAC) จำกัดสิทธิ์ให้ตรงกับงาน หรือการแยกหน้าที่ (segregation of duties) ที่ขาดไป

มุมเถ้าแก่: เรื่องนี้คือฝันร้ายกลางดึกของเจ้าของกิจการโดยตรง ถ้าคนคนเดียว ทำได้และปกปิดได้ พร้อมกัน (อนุมัติเอง บันทึกเอง, หรือพัฒนาโปรแกรมเองแล้วทดสอบเอง, หรือดูแลทรัพย์สินเองแล้วลงบัญชีเอง) นั่นคือรูที่เงินรั่วได้แบบไม่มีใครเห็น

มุมผู้ตรวจ: จุดที่หน้าที่ทับซ้อนกันแบบนั้นคือความเสี่ยงอันดับหนึ่งที่ต้องแก้ก่อน

⚠️ กับดัก: ข้อสอบชอบเอา การอบรม/สร้างความตระหนัก มาเสนอเป็นทางแก้ ทั้งที่ปัญหาจริงเป็นช่องโหว่ access หรือ SoD เชิงเทคนิค การอบรมให้ความรู้ได้ก็จริง แต่ไม่ได้จำกัดสิทธิ์ ส่วน การตรวจสอบเป็นระยะ, การสำรองข้อมูล (backup), รายงาน error, การ monitor พวกนี้ล้วนเป็น detective/recovery เจอทีหลังหรือกู้คืนได้ แต่ไม่ได้ ป้องกัน การแก้ข้อมูลตั้งแต่แรก แล้วก็ระวังตัวเลือกที่ over-restrict เกินงาน เช่น “ให้เฉพาะผู้บริหารเข้าถึงได้เท่านั้น” หรือ “ใช้ biometrics อย่างเดียว” ที่ไปขวางการทำงานจริง สรุปคือเมื่อมีตัวคุมเชิงป้องกันแบบ access/SoD ให้เลือก อย่าไปเลือกอันที่แค่ตรวจจับ กู้คืน อบรม หรือสำรวจ

Topical Requirements กับ emerging IT risk: ของใหม่ที่มาเสริม ไม่ได้มาแทน#

ตรงนี้เป็นเรื่องใหม่และเป็น emerging risk แท้ๆ Topical Requirements ของ The IIA คือข้อกำหนดที่วาง minimum baselines (เกณฑ์ขั้นต่ำ) สำหรับ assurance engagements ในหัวข้อเฉพาะที่ The IIA ออกประกาศไว้ เรื่องพวกนี้ไปเชื่อมกับ Principle 13 ที่ว่าด้วยการวางแผน engagement อย่างเป็นระบบ ใครอยากเข้าใจว่าพื้นฐาน IT ที่หนุนอยู่ข้างหลังคืออะไร เรื่องคอมพิวเตอร์ทำงานยังไงจริงๆ ไปดูได้ที่ IT Foundation ส่วนเรื่องฐานข้อมูลลึกๆ อยู่ที่ Database 101

หลักการใช้ Topical Requirement สามข้อ — ใช้ตามความเสี่ยง (ไม่ใช่ใส่อัตโนมัติ), เสริมไม่แทน the Standards, และ CAE รับผิดชอบหาทรัพยากรมารองรับ conformance — เล่าละเอียดไปแล้วตอน /posts/cia-p2-17-objectives-scope-criteria-topical-requirements/ ตรงนี้จำแค่แก่นพอ: การตัดสินว่าจะรวม requirement ไหนขึ้นอยู่กับ ความเข้าใจความเสี่ยงเทียบกับกลยุทธ์และวัตถุประสงค์ขององค์กร บวกดุลยพินิจเชิงวิชาชีพ ไม่ใช่ trigger เชิงกลไกอย่าง “effective date ผ่านแล้ว” หรือ “engagement เกี่ยวกับ vendor”

ส่วนที่เป็น IT โดยเฉพาะคือ หัวข้อที่ IIA ออก Topical Requirement บ่อยที่สุดล้วนเป็น emerging IT risk ที่วิวัฒน์เร็ว — cybersecurity, third-party technology, การจัดการข้อมูล พอความเสี่ยงพวกนี้เข้าเกณฑ์ significant ในงานตรวจด้าน IT ผู้ตรวจก็ต้องดึง requirement ที่เกี่ยวมาใช้เป็น baseline เพิ่มบน the Standards

control frameworks: จำลายนิ้วมือของแต่ละกรอบ#

ปิดท้ายกระเป๋าใบแรกด้วยเรื่อง control frameworks หลายองค์กรออกกรอบควบคุมมาให้ใช้ แต่ละอันมี “ลายนิ้วมือ” คือคุณสมบัติเด่นหนึ่งอย่างที่ชี้ว่าใช่อันนี้ เคล็ดคือฟังวลีในโจทย์ แล้วจับให้ตรงกรอบ ไม่ใช่เลือกชื่อที่ดังที่สุด

• COSO — สามเสาของวัตถุประสงค์การควบคุมภายใน: ประสิทธิผล/ประสิทธิภาพของการดำเนินงาน, ความน่าเชื่อถือของรายงาน, การปฏิบัติตามกฎระเบียบ (effectiveness/efficiency + reliability + compliance) เจอวลีนี้คือ COSO
• COBIT 2019 — กรอบ IT governance ที่รู้จักกว้างที่สุด จุดที่ต้องจำคือมันแยก governance ออกจาก management อย่างชัดเจน ในโจทย์แบบ “จริงทุกข้อ EXCEPT” ตัวเลือกที่บอกให้ รวม governance กับ management เข้าด้วยกัน คือข้อเท็จ (ซึ่งเป็นคำตอบ)
• ISO 27001 — มาตรฐาน information security management system เจอโจทย์ที่ถามหา benchmark เรื่องความมั่นคงปลอดภัยข้อมูล/IT อย่างเข้มงวด ให้เลือกอันนี้
• ISO 9000/9001 — quality management ถ้าโจทย์พูดถึงการ ติดตามความพึงพอใจลูกค้าเป็นตัววัดผล นั่นคือองค์ประกอบหลักของ ISO 9000 ไม่ใช่ control environment หรือ risk assessment
• ITIL — best practice ด้าน IT service management ใช้ bottom-up ตรงข้ามกับ COBIT ที่เป็น top-down governance

⚠️ กับดัก: พอเป็นโจทย์แนว IT สามเสาของ COSO มักถูกวางเป็นเหยื่อล่อทุกครั้งที่มีชื่อ IT-sounding อย่าง COBIT/eSAC โผล่มาด้วย เพราะชื่อที่ฟังเป็น IT มันรู้สึกใช่กว่าสำหรับโจทย์ IT แต่ให้ยึดวลี signature เป็นหลักไว้ และถ้าถามหา benchmark ความปลอดภัย IT อย่าเผลอไปเลือกกรอบทั่วไปอย่าง COSO/GAAP/ITIL เพราะอันที่ specific เรื่อง security คือ ISO 27001

⚠️ กับดัก: อีกแนวคือ “เข้าใจก่อน แล้วค่อยลงมือ” พอความรับผิดชอบยังไม่ชัด หรือกำลังจะเลือกกรอบ ตัวเลือกที่ถูกคือ ประเมินสิ่งที่มีอยู่ / นิยามโครงสร้างก่อน เช่น ตั้งคณะกรรมการ IT governance รวมศูนย์ความรับผิดชอบ, หรือประเมินกระบวนการ IT ปัจจุบันหาช่องว่างก่อนแล้วค่อยแนะนำกรอบ ส่วนตัวเลือกที่ผิดคือแนว “รีบซื้อเครื่องมือ security ใหม่” “จ้างคน IT เพิ่ม” “รีบ implement กรอบมาตรฐานเลย” หรือ “ให้แต่ละแผนกเขียนนโยบายของตัวเอง” จำไว้ว่าลงมือก่อนวินิจฉัยคือตัวหลอกเสมอ ส่วนงานสืบสวนความมั่นคงปลอดภัยเชิงลึก เรื่อง database administrator (DBA), การไหลของข้อมูลแบบ ETL (extract, transform, load) และหลักการ IT audit เต็มรูปแบบ เดี๋ยวมีปูพื้นไว้ในซีรีส์ CISA

ตารางกับดักรวม#

สิ่งที่จดสำหรับวันสอบ#

• real-time มีข้อดีเดียว = timeliness ข้อดีอื่นๆ (ประหยัด ตรวจง่าย) เป็นของ batch หมด
• สองโหมดอยู่ด้วยกันได้ เจอคำ absolute (ต้องเลือก / ดีกว่าเสมอ / ตกยุค) ให้ระวัง
• audit trail = อันที่ record ประวัติย้อนไปหาต้นตอ ไม่ใช่แค่ detect/alert/reconcile
• ย้ายมาคอมพิวเตอร์: วิธีเปลี่ยน หลักและเป้าหมายไม่เปลี่ยน และ fraud อาจ เพิ่ม ไม่ใช่ลด
• general = ทั้งบ้าน (พัฒนา/แก้โปรแกรม, access, ระบบใหม่), application = ห้องเดียว (edit ต่อรายการ) ต้องมั่นใจ general ก่อน
• จับความผิดให้ตรงตัวตรวจ: ไม่มีในไฟล์→validity, พิมพ์สลับหลัก→check digit, เกินช่วง→limit, ผิดประเภท→field, ว่าง→completeness
• sum-of-digits check digit จับ transposition ไม่ได้
• hash total = ผลรวม field ที่ไม่มีความหมาย (เลขพนักงาน/ใบแจ้งหนี้) จับความครบถ้วน
• input=ก่อน/ตอนเข้า, processing=ระหว่างประมวลในระบบ, output=หลังออกผล
• access/SoD ชนะ อบรม/backup/audit เป็นระยะเสมอ ในโจทย์ BEST/FIRST
• Topical Requirement: risk-based, เสริมไม่แทน the Standards, CAE จัดทรัพยากร — สามข้อนี้ท่องให้ขึ้นใจ
• framework จับลายนิ้วมือ: สามเสา→COSO, security→ISO 27001, ลูกค้าพึงพอใจ→ISO 9000, แยก governance/management→COBIT
• ตัวเลข Standard/Principle (เช่น Principle 13) — จำเจตนา ไม่ต้องท่องเลข

กระเป๋าใบแรกจัดเสร็จ ตอนหน้าเปิดใบที่สอง — เรื่องที่ต่อยอดจาก IT โดยตรง ทั้งความเสี่ยงไซเบอร์บน mobile/IoT/cloud, Cybersecurity Topical Requirement ที่เป็น baseline ใหม่, การจับ control ให้ตรงชั้น ไปจนถึง business resilience อย่าง BIA→BCP→DRP ตอนถัดไป: กระเป๋าไซเบอร์ ความเป็นส่วนตัว และความยืดหยุ่น

อ้างอิง: Gleim CIA Review (2026), Part 2 · IIA Global Internal Audit Standards (2024)