โครงของบท#

• control คืออะไร และทำไมมันให้ได้แค่ความเชื่อมั่นพอสมควร ไม่ใช่การันตี 100%
• inherent limitation สี่ตัวที่ไม่ว่าคุมดีแค่ไหนก็แก้ไม่ได้ — และมันต่างจาก “control ที่พลาด” ยังไง
• ใครเป็นเจ้าของ control ฝ่ายบริหารตั้ง ผู้ตรวจแค่ประเมิน — เส้นแบ่งที่ข้อสอบชอบลาก
• ตระกูลตามหน้าที่: preventive / detective / corrective / directive และแฝด primary/secondary, entity-level, people-based
• ตระกูลตามจังหวะเวลา: feedforward / concurrent / feedback (ก่อน–ระหว่าง–หลัง)
• โลก IT: general control (ITGC) กับ application control ที่แตกเป็น input / processing / output พร้อม edit check และ control total ที่ข้อสอบชอบสลับ

กลอนประตูคืออะไรกันแน่ — และมันกันได้แค่ไหน#

เริ่มจากนิยามก่อน เพราะข้อสอบชอบเล่นกับนิยามนี่แหละ control ตามศัพท์ทางการคือ “การกระทำใดๆ ที่ฝ่ายบริหาร board และคนอื่นๆ ทำเพื่อจัดการความเสี่ยงและเพิ่มโอกาสที่เป้าหมายจะสำเร็จ” ให้จับคำว่า การกระทำเพื่อจัดการความเสี่ยง ไว้ให้มั่น เพราะตัวหลอกที่ข้อสอบชอบวางคือเอา “เป้าหมายที่องค์กรอยากทำให้สำเร็จ” มาสวมรอยว่าเป็น control ทั้งที่นั่นมันคือ objective ไม่ใช่ control อีกตัวหลอกคือ “การทำงานให้มีประสิทธิภาพ” ซึ่งก็ไม่ใช่นิยามของ control เหมือนกัน กลอนไม่ใช่ตัวบ้าน กลอนคือสิ่งที่เอาไปล็อกบ้านต่างหาก

ทีนี้ประเด็นที่โคตรสำคัญ control ให้ได้แค่ reasonable assurance (ความเชื่อมั่นพอสมควร) ไม่เคยให้ absolute assurance ลองคิดดูนะครับ กลอนดีแค่ไหนก็มีคนสะเดาะได้ แล้วถ้าเจ้าของกุญแจตั้งใจจะโกงเอง กลอนก็ช่วยอะไรไม่ได้เลย นี่แหละเหตุผลว่าทำไมทุก system of internal control ถึงมี inherent limitation ข้อจำกัดที่ฝังมาในตัว ต่อให้ออกแบบเทพแค่ไหนก็ลบทิ้งไม่ได้ มีอยู่สี่ตัว:

• human judgment ที่ผิดพลาด — คนตัดสินใจพลาด อ่านสถานการณ์ผิด control ก็พังเพราะความผิดพลาดง่ายๆ ของมนุษย์
• management override — ฝ่ายบริหารข้ามหน้าข้ามตา control ที่ตัวเองตั้งขึ้น เช่น สั่งจ่ายเช็คทั้งที่ไม่มีใบสั่งซื้อ เพื่อปั้นตัวเลขรายได้หรือซ่อนหนี้
• collusion — สองคนขึ้นไปสมคบกันเจาะ control ที่ออกแบบไว้ให้ต้องมีหลายคนถ่วงดุลกัน
• cost-benefit — ต้นทุนของ control ต้องไม่แพงกว่าประโยชน์ที่ได้ ถ้าค่ากลอนแพงกว่าของที่กลอนป้องกัน ก็ไม่คุ้มจะใส่

มุมเถ้าแก่/สภา: เรื่องนี้กระทบการนอนหลับของเจ้าของตรงๆ เพราะมันแปลว่า “ต่อให้ฉันจ้างที่ปรึกษามาวางระบบแพงแค่ไหน ก็ไม่มีทางกันโกงได้ 100%” สภาต้องยอมรับความจริงข้อนี้ แล้วโฟกัสไปที่ว่า control ที่มี คุ้ม หรือเปล่า ไม่ใช่ไล่ใส่ control ทุกอันแบบไม่ดูราคา

มุมผู้ตรวจ (คนสอบ): ตรงนี้แหละเหมืองทองของ trap ครับ ถ้าโจทย์ถามว่า “อันไหนคือ inherent limitation” แล้ววางตัวเลือกมาปนกันมั่วๆ วิธีคิดที่ผมใช้แล้วไม่พลาดคือถามตัวเองว่า “องค์กรที่บริหารดีเยี่ยมจะลบสิ่งนี้ทิ้งได้หมดไหม?”

• ถ้า ไม่ได้ (collusion, override, human judgment, cost-benefit) → นี่คือ inherent limitation
• ถ้า ได้ — มันคือ control ที่มีอยู่ หรือ control ที่ขาด/ทำช้า/ทำลวกๆ → ไม่ใช่ limitation

⚠️ กับดัก: ข้อสอบชอบเอา control activity มาปลอมเป็น limitation — พวก segregation of duties (การแบ่งแยกหน้าที่), incompatible duties, audit trail, การประเมินพนักงาน สิ่งเหล่านี้คือ control ไม่ใช่ข้อจำกัด อีกกับดักคือเอา control ที่พลาด มาปลอม เช่น กระทบยอดธนาคารไม่สม่ำเสมอ ไม่เช็คเครดิตลูกค้าก่อนขาย เอกสารส่งของไม่ match กัน — พวกนี้คือความพลาดที่ แก้ได้ จึงไม่ใช่ inherent limitation

⚠️ กับดัก: เจอคำว่า eliminate / guarantee / ensure / cannot be circumvented / all เมื่อไหร่ ให้ระวังไว้เลย control ไม่มีวัน “กำจัดการทุจริตทั้งหมด” หรือ “ทำให้บรรลุเป้าหมายแน่นอน” ตัวเลือกที่พูดแบบการันตีมักผิดเสมอ ตัวเลือกที่ถูกคือตัวที่ยอมรับความจำกัด เช่น “ช่วยปกป้องสินทรัพย์” (assists safeguarding) ไม่ใช่ “กำจัดความเสี่ยง”

⚠️ กับดัก: มีมุมกลับที่โหดกว่า — โจทย์ถามว่า “อันไหนคือ limitation ไม่ใช่ failure” แล้ววางเคสขโมยเงินคนเดียว (พนักงานคนเดียว เสมียนคนเดียว) ปนกับเคสรับสินบนแบบสมคบ ตรงนี้ต้องแยกให้ขาด: ขโมยคนเดียวคือความพลาดที่ control ป้องกันได้ (จึงเป็น failure) แต่ สมคบ/รับสินบนสองฝ่ายคือสิ่งที่หลุดรอด control ได้เสมอ (จึงเป็น limitation) เจอ “understaffed internal audit function” หรือ “board ที่ไม่มีประสิทธิภาพ” อย่าไปหลง — พวกนั้นคือจุดอ่อนที่ แก้ได้ ไม่ใช่สิ่งที่หลีกเลี่ยงไม่ได้

เจ้านายชนะกลอนเสมอ — management override#

ขอแยก override ออกมาเป็นหัวข้อของมันเองเลย เพราะมันโผล่บ่อยจนต้องจำเป็น pattern พอจับหลักได้แล้วมันง่ายมากครับ: คนที่สร้าง control ย่อมล้ม control ได้ ฝ่ายบริหาร establish (ตั้ง) controls ขึ้นมาเอง ก็เลย override (ข้าม) มันได้ด้วย นี่แหละที่มันเป็นทั้ง inherent limitation ถาวร และเป็น fraud risk ที่ผู้ตรวจต้องทดสอบเสมอ

มุมเถ้าแก่/สภา: ลองนึกภาพ CEO โทรสั่งฝ่ายบัญชีให้จ่ายเช็คก้อนใหญ่ทันที “ไม่ต้องรอใบสั่งซื้อหรอก ผมรับผิดชอบเอง” — control ทั้งระบบที่วางไว้ว่าต้องมี PO ก่อนถูกข้ามในพริบตา สภาจึงต้องออกแบบให้มีคนที่ CEO ข้ามไม่ได้ เช่น กระบวนการเทียบยอดใช้จ่ายจริงกับวงเงินที่อนุมัติไว้ ซึ่งเป็นด่านที่ override จะโผล่ออกมาเป็นตัวเลขที่เกินกรอบ

มุมผู้ตรวจ (คนสอบ): โจทย์ชอบถามว่า “จะทดสอบ override ยังไงดีที่สุด” คำตอบคือ เทียบรายจ่ายจริงกับวงเงิน/งบที่อนุมัติ ถ้ามี variance ที่เกินกรอบ นั่นแหละสัญญาณว่าวงเงินถูกข้าม

⚠️ กับดัก: ข้อสอบจะวางการทดสอบแบบ matching/tracing ที่ดูดีแต่ไม่ตอบโจทย์ — เช่น จับคู่ PO กับ AP, trace ใบสั่งขายไปหารายได้, อ่านรายงานการประชุม board การทดสอบพวกนี้ยืนยันแค่ว่า “รายการถูกบันทึกและถูกอนุมัติ” แต่ ไม่เผย ว่ามีการอนุมัติที่ถูก override ไปแล้ว การอ่าน board minutes บอกได้แค่ว่ามีการอนุมัติ ไม่ได้บอกว่าการอนุมัตินั้นถูกข้ามหน้า

⚠️ กับดัก: ถ้าถามว่า “อะไรเพิ่มความเสี่ยงที่ผู้ตรวจจะ พลาด การทุจริต” ตัวหลอกจะเป็นของไม่มีพิษภัย เช่น “ไม่มีระบบรางวัล” หรือ “board ทบทวน audit plan” — คำตอบที่ถูกคือ management override เท่านั้น

ใครถือกลอน ใครแค่ตรวจกลอน#

เส้นแบ่งนี้คือลายเซ็นของทั้งวิชาชีพเลยครับ และข้อสอบก็ลากเส้นนี้ซ้ำแล้วซ้ำอีก ฝ่ายบริหารตั้งและดูแล control และเป็นเจ้าของความเสี่ยง ส่วน internal audit function แค่ประเมินว่า control มีประสิทธิผลไหมและส่งเสริมให้ปรับปรุงต่อเนื่อง ไม่เคยออกแบบ ไม่เคยรัน ไม่เคยเฝ้าสินทรัพย์

มุมเถ้าแก่/สภา: senior management ดูแลการตั้ง การบริหาร และการประเมินระบบ control ผู้จัดการแต่ละแผนกประเมิน control ในความรับผิดชอบของตัวเอง ส่วนผู้ตรวจสอบภายในให้ การให้ความเชื่อมั่น (assurance) แบบอิสระและเที่ยงธรรมว่า control พวกนั้นได้ผลจริงไหม เถ้าแก่ต้องเข้าใจว่าถ้ากลอนพัง คนที่ต้องรับผิดชอบซ่อมคือฝ่ายปฏิบัติ ไม่ใช่คนที่มาตรวจว่ากลอนใช้ได้ไหม

มุมผู้ตรวจ (คนสอบ): วิธีทำโจทย์คือคัดหน้าที่แต่ละอันเข้าเจ้าของ

• ตั้ง / ดูแล / บริหาร / เป็นเจ้าของความเสี่ยง / เฝ้าสินทรัพย์ → ฝ่ายบริหาร (หรือฝ่ายปฏิบัติ)
• ประเมินประสิทธิผลและประสิทธิภาพ / ส่งเสริมการปรับปรุงต่อเนื่อง → internal audit function

⚠️ กับดัก: ตัวหลอกคลาสสิคคือยัดหน้าที่ของฝ่ายบริหารมาให้ผู้ตรวจ เช่น “ตั้งและรักษา control” “บริหารระบบ control” หรือ “การเฝ้าสินทรัพย์ (safeguarding of assets)” — อันหลังนี่เป็นงาน ปฏิบัติการ อยู่นอกขอบเขตของ internal audit เลย ถ้าโจทย์ถามว่า “อันไหน อยู่นอก ขอบเขตของ internal auditing” คำตอบคือ safeguarding of assets ผู้ตรวจแค่ประเมิน control ที่คุมการเฝ้าสินทรัพย์ ไม่ได้ลงไปเฝ้าเอง

ตระกูลตามหน้าที่ — กลอนสี่พันธุ์#

ทีนี้เข้าเนื้อของ 8.2 กันจริงจังครับ Gleim แบ่ง control ออกเป็น primary internal control (control หลัก หรือ key control) กับ secondary control (control เสริม) primary คือด่านหลักที่ตั้งไว้กันปัญหาตรงๆ ส่วน secondary คือชั้นสำรองที่คอยรับสิ่งที่หลุดจากด่านหลักมาอีกที

ในกลุ่ม primary มีสี่พันธุ์ วิธีจำที่ไม่พลาดคือถามว่า “มันทำงานตอนไหนเทียบกับเหตุการณ์ร้าย?”

• preventive — ทำงาน ก่อน เพื่อกันไม่ให้เกิด เช่น เก็บเงินสดย่อยในตู้เซฟล็อก, แบ่งแยกหน้าที่, อนุมัติเครดิตลูกค้าก่อนส่งของ, บังคับให้กรอกจำนวนใบแจ้งหนี้ในชุดก่อนเริ่มประมวลผล, ออกแบบฐานข้อมูลไม่ให้ใส่ตัวอักษรในช่องเลขประกันสังคม
• detective — ทำงาน หลัง เพื่อค้นเจอเหตุที่เกิดไปแล้ว มันเป็น active control เพราะต้องมีคนเข้ามาแทรก เช่น กระทบยอด, ทบทวน log เช็ค, สแกนบัญชีแยกประเภท, ทบทวนลำดับเลขที่พิมพ์ล่วงหน้า, เสมียนขอสำเนาใบแจ้งหนี้ที่หายไป
• corrective — ทำงาน หลังค้นเจอ เพื่อแก้ผลเสีย เช่น บังคับให้ทุก cost variance ที่เกินกรอบต้องมีคำชี้แจง, เก็บ backup สะอาดไว้กู้คืน
• directive — ส่งเสริม ให้เกิดสิ่งที่พึงประสงค์ เช่น คู่มือนโยบายและระเบียบปฏิบัติ, การอบรมพนักงาน, job description, การกำหนดให้ผู้ตรวจทุกคนต้องมีวุฒิ CIA

มุมเถ้าแก่/สภา: เถ้าแก่ต้องรู้ว่าเงินที่ลงกับ control แต่ละพันธุ์ซื้ออะไร preventive คือกันไม่ให้เจ็บตัวตั้งแต่แรก (ถูกที่สุดในระยะยาว) detective คือยอมให้เกิดแต่รีบจับได้ก่อนเสียหายหนัก directive คือการวางวัฒนธรรมให้คนทำถูกเอง ส่วน corrective คือแผนสำรองตอนพลาดไปแล้ว

มุมผู้ตรวจ (คนสอบ): map ทุกตัวเลือกลงบนเส้นเวลาเหตุการณ์ ก่อน–หลังค้น–หลังแก้–ส่งเสริม แล้วจะไม่หลง

⚠️ กับดัก: ตัวที่ดูเหมือน preventive แต่จริงๆ เป็น detective — พวกกระทบยอด, ทบทวน log, การเปรียบเทียบ, สแกนบัญชี, ทบทวนลำดับเลขที่พิมพ์ล่วงหน้า สิ่งเหล่านี้ ค้นเจอ เหตุที่เกิดไปแล้ว ไม่ได้กันล่วงหน้า ในทางกลับกัน segregation of duties, การอนุมัติก่อนลงมือ, สต็อกล็อกกุญแจ, อนุมัติเครดิตก่อนส่งของ พวกนี้คือ preventive ไม่ใช่ directive

⚠️ กับดัก: directive คือตัวแปลกในกลุ่ม มันไม่ได้กันหรือจับ แต่ กระตุ้น พฤติกรรมดี — คู่มือ, อบรม, การกำหนดคุณสมบัติ ถ้าโจทย์สลับถามว่า “อันไหน detective” ตัวเลือกกระทบยอด/log/เปรียบเทียบจะกลายเป็นคำตอบ ส่วนตัวอนุมัติ/ล็อกกุญแจกลายเป็นตัวหลอกทันที มุมกลับได้ตลอด

ตระกูลตามจังหวะเวลา — ก่อน ระหว่าง หลัง#

อีกวิธีมองที่ข้อสอบชอบเล่นคือมองตามตำแหน่งบนเส้นเวลาของ กิจกรรม ไม่ใช่เส้นเวลาของ เหตุร้าย คนละเลนส์กับ preventive/detective เลยนะครับ ตรงนี้ผมว่าต้องแยกให้ขาดจริงๆ

• feedforward — คาดการณ์และป้องกันล่วงหน้า มองไกล เช่น การจัดทำงบประมาณ, การพยากรณ์, อบรม quality control, นโยบายและระเบียบปฏิบัติ, การวิเคราะห์ตอนพัฒนาระบบ, การแจ้งล่วงหน้าก่อนซื้อเครื่องจักร (มีอีกชื่อว่า preliminary control)
• concurrent — ปรับกระบวนการที่กำลังดำเนินอยู่ ณ ปัจจุบัน เช่น การกำกับดูแลคนงานสายพานการผลิตอย่างใกล้ชิด
• feedback — วัดกิจกรรมที่ เสร็จแล้ว เพื่อปรับรอบถัดไปให้ดีขึ้น เช่น การวิเคราะห์ variance, การตรวจสินค้าสำเร็จรูป, การเฝ้าดูสินค้าคืน/คำร้องเรียน

มุมเถ้าแก่/สภา: feedforward คือการวางงบและนโยบายก่อนเปิดไลน์ผลิต concurrent คือหัวหน้ายืนคุมหน้างานสดๆ feedback คือประชุมสรุปหลังปิดรอบว่าเดือนนี้พลาดตรงไหน ทั้งสามอันเถ้าแก่ใช้จริงทุกวันโดยไม่รู้ชื่อมัน

มุมผู้ตรวจ (คนสอบ): วางตัวเลือกลงบนเส้นเวลากิจกรรม — คาดการณ์/นำหน้า = feedforward, ปรับกลางคัน = concurrent, วัดของที่เสร็จแล้ว = feedback

⚠️ กับดัก: งบประมาณ พยากรณ์ อบรม QC นโยบาย/ระเบียบ การแจ้งล่วงหน้า ทั้งหมดนี้ รู้สึก เหมือน control ธรรมดา แต่มันคือ feedforward เพราะมุ่งไปอนาคต ในทางกลับกัน การตรวจสินค้า ที่ทำเสร็จแล้ว, เฝ้าดูสินค้าคืน, วิเคราะห์ variance คือ feedback — อย่าเรียกมันว่า feedforward แค่เพราะมันหวังจะปรับปรุงอนาคต เกณฑ์คือมัน กระทำกับสิ่งที่เกิดไปแล้ว และการกำกับดูแลคนงานไลน์ผลิตอย่างใกล้ชิดคือ concurrent ไม่ใช่ feedback เพราะมันปรับกระบวนการที่กำลังเดินอยู่

โลก IT — สองชั้นที่ต้องแยกก่อนตอบ#

พอเข้าเรื่อง control ในระบบคอมพิวเตอร์ กับดักมันเปลี่ยนหน้าไป แต่ตรรกะยังเดิมนะครับ สิ่งแรกที่ต้องทำคือถามว่า control ตัวนี้มันอยู่ ชั้นไหน — general control (ITGC) ที่ครอบทั้งสภาพแวดล้อม IT ทั้งองค์กร หรือ application control ที่ฝังอยู่ในแอปเดียว/กระบวนการเดียว

ITGC คือร่มใหญ่ที่ฝ่ายบริหารอนุมัติ ครอบงานทั้งหมดไว้ ได้แก่ การควบคุมการเข้าถึงเชิงตรรกะ (logical access เช่น password), การควบคุมวงจรพัฒนาระบบและการเปลี่ยนแปลงโปรแกรม (SDLC / program change), การรักษาความปลอดภัยทางกายภาพของ data center, แล้วก็ backup กับ recovery ทั้งหมดนี้มีเป้าเดียวคือประกันความถูกต้องของ program file, data file และการดำเนินงานของคอมพิวเตอร์โดยรวม

ถ้าไม่ใช่ ITGC มันก็คือ application control ซึ่งแตกเป็นสามด่านตามการไหลของข้อมูล:

• input control — ทำงานตอนข้อมูล เข้า ประกันว่า input ถูกต้อง ครบถ้วน ได้รับอนุมัติ และ valid เช่นดักค่า “400 ชั่วโมง” ที่ควรเป็น 40 ก่อนมันจะเข้าระบบ input เป็นจุดที่ผู้ตรวจโฟกัสมากที่สุด เพราะ เวลาที่ประหยัดที่สุดในการแก้ error คือตอนป้อนข้อมูล
• processing control — ทำงานระหว่าง ปรับปรุง ข้อมูล เช่น การกระทบยอดอัตโนมัติ, integrity control, transaction log, zero-balance check ที่ปฏิเสธชุดที่เดบิตกับเครดิตไม่เท่ากัน, concurrency control ที่กันการจองที่นั่งเครื่องบินซ้ำ
• output control — ทำงาน หลัง ประมวลผล เช่น การทบทวน processing log, log การแจกจ่ายรายงาน, run control total, และ user review ที่ให้ผู้ใช้เช็คว่าผลลัพธ์สมเหตุสมผลไหม

มุมเถ้าแก่/สภา: เถ้าแก่ไม่ต้องรู้โค้ด แต่ต้องรู้ว่าเงินลงระบบ IT แบ่งเป็นสองก้อน — ก้อนที่คุมทั้งโรง (ใครเข้าถึงได้บ้าง ใครแก้โปรแกรมได้ ข้อมูลสำรองไว้ไหม) กับก้อนที่คุมกระบวนการเดียว (ใบเงินเดือนคำนวณถูกไหม) ถ้าร่มใหญ่รั่ว control รายแอปก็เชื่อถือไม่ได้ตามไปด้วย

มุมผู้ตรวจ (คนสอบ): ทำสองสเต็ป — ถามก่อนว่ากว้างทั้งระบบไหม (access, SDLC, program change, backup, configuration = ITGC) ถ้าไม่ใช่ค่อยเลือกด่าน: เข้า/ปรับปรุง/ออก

⚠️ กับดัก: การทบทวน/อนุมัติระบบใหม่, program change control, logical access, backup, configuration ล้วนเป็น general control ถึงแม้ชื่อจะฟังดูเจาะจงแอป อย่าไปเรียกมันว่า input หรือ processing control และมุมกลับที่โหด — โจทย์ถามว่า “อันไหน สำคัญน้อยที่สุด เมื่อทบทวน input control ของแอป” คำตอบคือ configuration เพราะมันเป็นเรื่องของ ITGC ไม่ใช่ระดับแอป

⚠️ กับดัก: input กับ processing สลับกันบ่อย — input ดักตอนข้อมูล เข้า (จับ 400 ชั่วโมงก่อนเข้า) ส่วน processing ทำงานตอน ปรับปรุง (กระทบยอดอัตโนมัติ, transaction log, ปฏิเสธ zero-balance ระหว่างลงบัญชี) และ output ทำงาน หลัง ประมวลผล (ทบทวน processing log, log แจกจ่าย)

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

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

• control = การกระทำจัดการความเสี่ยง ไม่ใช่ objective ไม่ใช่ “การทำงานมีประสิทธิภาพ”
• reasonable assurance เท่านั้น — เจอ eliminate/guarantee/ensure/all/cannot be = สงสัยผิดไว้ก่อน
• inherent limitation สี่ตัว: human judgment, management override, collusion, cost-benefit — ทั้งหมดแก้ไม่ได้ ตัวที่ แก้ได้ คือ control ที่ขาดหรือพลาด ไม่ใช่ limitation
• ขโมย คนเดียว = failure (ป้องกันได้) / สมคบ = limitation (หลุดรอดได้)
• ทดสอบ override = เทียบจ่ายจริง vs วงเงินอนุมัติ ไม่ใช่ matching/tracing
• ฝ่ายบริหารตั้ง+เป็นเจ้าของ / IA แค่ประเมิน — safeguarding assets อยู่ นอก ขอบเขต IA
• พันธุ์ตามหน้าที่: ก่อน=preventive, หลัง(ค้น)=detective, หลัง(แก้)=corrective, ส่งเสริม=directive — กระทบยอด/log = detective เสมอ
• จังหวะเวลา: feedforward=ก่อน, concurrent=ระหว่าง, feedback=หลัง(ของที่เสร็จ) — คนละเลนส์กับ preventive/detective
• IT สองชั้น: ITGC=ทั้งระบบ (access/SDLC/change/backup/config) → application=แอปเดียว แตกเป็น เข้า/ปรับปรุง/ออก
• edit check: เลขผิด=check digit, ไม่อยู่ในลิสต์=validity, ผิดชนิดตัวอักษร=field/format, เกินพิสัย=limit, ช่องว่าง=completeness
• control total: hash=ผลรวมไร้ความหมาย (ครบถ้วนอย่างเดียว), record=นับ, financial=เงินจริง
• compensating control ลำพังไม่พอ ต้องพึ่งตัวอื่น / complementary ทำงานร่วมกันแล้วดีกว่า
• control ตัวเดียวจัดได้หลายหมวดพร้อมกัน — ไม่ต้องบังคับให้เข้าช่องเดียว

รู้จักตระกูล control ครบแล้ว แต่รู้จักชื่อกับเอาไปติดตั้งจริงในวงจรบัญชีขององค์กรมันคนละเรื่องกัน ตอนหน้าเราลากทฤษฎีลงหน้างาน — แยกหน้าที่ authorize/record/custody เดินเข้าวงจรขาย-รับ-จ่าย-payroll จริง ตอนถัดไป: control ในสนามจริง ครับ

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