ITGC คืออะไร และต่างจาก ITAC อย่างไร
การควบคุมด้านไอทีที่เกี่ยวกับรายงานทางการเงินแบ่งเป็นสองชั้น และการสับสนระหว่างสองชั้นนี้เป็นสาเหตุที่ทำให้หลายองค์กรตอบคำถามผู้สอบบัญชีไม่ตรงคำถาม
ชั้นแรก คือ การควบคุมระดับแอปพลิเคชัน (Application Controls หรือ ITAC) เป็นการควบคุมที่ฝังอยู่ในระบบงานและทำงานกับรายการแต่ละรายการ เช่น ระบบไม่ยอมให้บันทึกใบกำกับภาษีที่ไม่มีเลขประจำตัวผู้เสียภาษี ระบบเตือนเมื่อยอดเดบิตไม่เท่ายอดเครดิต หรือระบบตัดยอดสินค้าคงเหลืออัตโนมัติเมื่อออกใบส่งของ
ชั้นที่สอง คือ การควบคุมทั่วไปด้านเทคโนโลยีสารสนเทศ (IT General Controls หรือ ITGC) เป็นการควบคุมสภาพแวดล้อมที่ระบบงานทั้งหมดอาศัยอยู่ ไม่ได้ทำงานกับรายการใดรายการหนึ่งโดยตรง แต่เป็นสิ่งที่ทำให้เชื่อได้ว่าการควบคุมในชั้นแรกยังทำงานเหมือนเดิมตลอดงวด
ความสัมพันธ์ระหว่างสองชั้นนี้เป็นแบบพึ่งพา ไม่ใช่แบบขนาน สมมติว่าระบบตรวจสอบวงเงินอนุมัติได้ถูกต้องสมบูรณ์ แต่ฝ่ายไอทีสามารถแก้ตารางวงเงินในฐานข้อมูลได้โดยไม่ต้องขออนุมัติและไม่มีร่องรอย การควบคุมวงเงินนั้นก็ไม่มีความหมายในเชิงการตรวจสอบ ด้วยเหตุนี้ ผู้สอบบัญชีที่ตั้งใจจะพึ่งพาการควบคุมในระบบงานจะพิจารณาด้วยว่า ITGC ที่รองรับระบบนั้นได้ผลหรือไม่ มาตรฐานการสอบบัญชี รหัส 315 (ปรับปรุง 2564) ย่อหน้าที่ ก166 ยกตัวอย่างว่า ถ้า ITGC ไม่ได้ป้องกันหรือตรวจพบการแก้โปรแกรมหรือการเข้าระบบโดยไม่ได้รับอนุญาต อาจกระทบการตัดสินใจของผู้สอบบัญชีว่าจะพึ่งพาการควบคุมอัตโนมัติในระบบนั้นหรือไม่
ในเชิงมาตรฐาน มาตรฐานฉบับเดียวกันกำหนดให้ผู้สอบบัญชีทำความเข้าใจการใช้เทคโนโลยีสารสนเทศของกิจการ และสำหรับระบบที่เกี่ยวกับการควบคุมที่ผู้สอบบัญชีระบุไว้และอาจมีความเสี่ยงที่เกิดจากการใช้ไอที ให้ระบุความเสี่ยงเหล่านั้นและการควบคุมทั่วไปด้านไอทีที่ตอบสนองความเสี่ยงดังกล่าว ส่วนในมุมของการควบคุมภายใน กรอบ COSO Internal Control: Integrated Framework หลักการที่ 11 ว่าด้วยการคัดเลือกและพัฒนากิจกรรมการควบคุมทั่วไปด้านเทคโนโลยีเพื่อสนับสนุนการบรรลุวัตถุประสงค์
สี่กลุ่มของ ITGC และหลักฐานที่ต้องจัดเตรียม
กลุ่มที่ 1 การเข้าถึงโปรแกรมและข้อมูล ตอบคำถามว่าใครเข้าระบบได้ ทำอะไรได้ และใครให้สิทธินั้น ครอบคลุมตั้งแต่การขออนุมัติสิทธิเมื่อพนักงานเข้าใหม่ การปรับสิทธิเมื่อย้ายตำแหน่ง การถอนสิทธิเมื่อลาออก การทบทวนสิทธิตามรอบ การตั้งค่ารหัสผ่าน และการควบคุมบัญชีผู้ใช้สิทธิสูงอย่างผู้ดูแลระบบ หลักฐานที่ถูกขอบ่อยคือ รายชื่อผู้ใช้งานทั้งหมดในระบบ ณ วันที่กำหนด ใบขออนุมัติสิทธิของตัวอย่างที่สุ่ม รายชื่อผู้ลาออกในงวดเทียบกับสถานะบัญชีในระบบ และเอกสารการทบทวนสิทธิที่มีผู้อนุมัติลงนาม ข้อบกพร่องที่พบบ่อยที่สุดคือบัญชีผู้ลาออกที่ยังไม่ถูกปิด และบัญชีกลางที่ใช้ร่วมกันหลายคนจนระบุตัวผู้กระทำไม่ได้
กลุ่มที่ 2 การบริหารการเปลี่ยนแปลงโปรแกรม ตอบคำถามว่าโปรแกรมที่ใช้อยู่วันนี้เป็นเวอร์ชันที่ได้รับอนุมัติและผ่านการทดสอบแล้วหรือไม่ ครอบคลุมการขออนุมัติก่อนแก้ไข การทดสอบและการยอมรับผลทดสอบโดยผู้ใช้ การแยกสภาพแวดล้อมพัฒนา ทดสอบ และใช้งานจริงออกจากกัน การแยกหน้าที่ระหว่างผู้เขียนโปรแกรมกับผู้นำโปรแกรมขึ้นใช้งาน และการควบคุมการแก้ไขฉุกเฉิน
ซึ่งหลักฐานที่ถูกขอบ่อย คือ ทะเบียนรายการเปลี่ยนแปลงทั้งงวด ใบขออนุมัติและผลการทดสอบของตัวอย่างที่สุ่ม และรายชื่อผู้มีสิทธินำโปรแกรมขึ้นใช้งานจริง
จุดที่มักเป็นปัญหา คือ การแก้ไขฉุกเฉินที่ทำก่อนแล้วค่อยขออนุมัติย้อนหลัง ซึ่งยอมรับได้ถ้ามีกระบวนการกำกับและสอบทานภายหลังที่ชัดเจน แต่มักไม่มีเอกสารรองรับ
กลุ่มที่ 3 การพัฒนาและการนำระบบใหม่มาใช้ ตอบคำถามว่าระบบที่เพิ่งเริ่มใช้ในงวดนี้เชื่อถือได้ตั้งแต่วันแรกหรือไม่ ครอบคลุมการกำหนดความต้องการ การทดสอบก่อนใช้งานจริง การอนุมัติรับมอบระบบ การฝึกอบรมผู้ใช้ และที่สำคัญที่สุดสำหรับงานบัญชีคือการย้ายข้อมูลจากระบบเดิม หลักฐานที่ถูกขอบ่อยคือ เอกสารการกระทบยอดข้อมูลที่ย้ายมา โดยเฉพาะยอดยกมาของลูกหนี้ เจ้าหนี้ สินค้าคงเหลือ และสินทรัพย์ถาวร พร้อมผู้อนุมัติ กลุ่มนี้มักถูกมองข้ามเพราะเกิดไม่บ่อย แต่เมื่อเกิดแล้วความเสียหายกระจุกตัวและกระทบงบการเงินโดยตรง ส่วนในมาตรฐานการสอบบัญชี รหัส 315 (ปรับปรุง 2564) ภาคผนวก 6 การพัฒนาหรือซื้อระบบและการแปลงข้อมูลเป็นตัวอย่างในกระบวนการจัดการการเปลี่ยนแปลง ไม่ได้แยกเป็นกลุ่มของตัวเอง
กลุ่มที่ 4 การปฏิบัติงานคอมพิวเตอร์ ตอบคำถามว่าระบบทำงานได้ต่อเนื่องและข้อมูลกู้คืนได้จริงหรือไม่ ครอบคลุมการเฝ้าระวังงานประมวลผลตามกำหนดเวลา การจัดการเหตุขัดข้อง การสำรองข้อมูล และการทดสอบกู้คืน หลักฐานที่ถูกขอบ่อยคือ รายงานผลการประมวลผลงานที่ตั้งเวลาไว้ ทะเบียนเหตุขัดข้องพร้อมการแก้ไข บันทึกผลการสำรองข้อมูล และรายงานผลการทดสอบกู้คืนที่ระบุวันที่ ขอบเขต และผลลัพธ์ คำว่าทดสอบกู้คืนในที่นี้หมายถึงการกู้ข้อมูลกลับมาจริงแล้วตรวจว่าใช้งานได้ ไม่ใช่การดูว่างานสำรองข้อมูลขึ้นสถานะสำเร็จ
ITGC เมื่อระบบอยู่บนคลาวด์
เมื่อองค์กรใช้ระบบบัญชีแบบบริการบนคลาวด์ คำถามที่ได้ยินบ่อยคือยังต้องมี ITGC อยู่หรือไม่ คำตอบคือ ยังมีส่วนที่เป็นหน้าที่ขององค์กร แต่ขอบเขตเปลี่ยนไป
การควบคุมส่วนที่เกี่ยวกับโครงสร้างพื้นฐาน เช่น การดูแลเครื่องแม่ข่าย การสำรองข้อมูลระดับระบบ และการติดตั้งแพตช์ ย้ายไปอยู่กับผู้ให้บริการ องค์กรจึงมักขอรายงานการตรวจสอบการควบคุมของผู้ให้บริการ เช่น รายงาน SOC มาเป็นหลักฐานแทนการตรวจเอง
แต่มีสองเรื่องที่มักอ่านข้าม
เรื่องแรก คือ รายงานเหล่านี้ระบุช่วงเวลาที่ครอบคลุมไว้ชัดเจน หากช่วงเวลาในรายงานไม่คลุมงวดบัญชีที่กำลังตรวจ จะต้องมีหลักฐานเพิ่มเติมสำหรับช่วงที่ขาดไป
เรื่องที่สอง คือ รายงานเหล่านี้มักมีส่วนที่ระบุการควบคุมซึ่งองค์กรผู้ใช้บริการต้องมีเอง เรียกว่า Complementary User Entity Controls ซึ่งโดยทั่วไปคือการบริหารสิทธิผู้ใช้ การอนุมัติการตั้งค่าที่กระทบการบันทึกบัญชี และการสอบทานรายงาน ส่วนนี้เป็นความรับผิดชอบขององค์กร ไม่ใช่ของผู้ให้บริการ
ในทางปฏิบัติ สิ่งที่องค์กรยังต้องทำเองแทบทั้งหมดคือกลุ่มที่ 1 คือการบริหารสิทธิผู้ใช้ รวมถึงการควบคุมการเปลี่ยนการตั้งค่าที่กระทบการบันทึกบัญชี เช่น การแก้ผังบัญชี การแก้เงื่อนไขการคำนวณภาษี หรือการเปิดสิทธิแก้ไขเอกสารย้อนหลัง ซึ่งเป็นการเปลี่ยนแปลงที่ทำได้จากหน้าจอโดยไม่ต้องเขียนโปรแกรม และมักไม่มีใครมองว่าเป็นการเปลี่ยนแปลงระบบ
ทำไม ITGC ที่ไม่ผ่านจึงกระทบงบการเงินและการเตรียม IPO
ผลกระทบแรก คือ ขอบเขตการตรวจสอบและค่าใช้จ่ายที่ตามมา
เมื่อ ITGC ไม่มีประสิทธิผล ผู้สอบบัญชีอาจพึ่งพาการควบคุมในระบบงานไม่ได้ และอาจต้องตอบสนองความเสี่ยงด้วยการตรวจสอบเนื้อหาสาระในปริมาณที่มากขึ้น ขนาดตัวอย่างที่ใหญ่ขึ้น นั่นแปลว่าเวลาที่ทีมงานต้องเตรียมเอกสารมากขึ้น และแน่นอน อาจส่งผลต่อค่าตรวจสอบที่สูงขึ้นตามไปด้วย และถ้าการตรวจสอบเนื้อหาสาระเพียงอย่างเดียวให้หลักฐานที่เหมาะสมอย่างเพียงพอไม่ได้ ผู้สอบบัญชีอาจพิจารณาผลกระทบต่อการแสดงความเห็น ตามตัวอย่างในย่อหน้าที่ ก166 ของมาตรฐานการสอบบัญชี รหัส 315 (ปรับปรุง 2564)
ผลกระทบที่สอง คือ การประเมินข้อบกพร่อง ข้อบกพร่องด้าน ITGC บางประเภทถูกยกระดับได้ เช่น การที่ผู้ใช้ทั่วไปมีสิทธิเข้าถึงฐานข้อมูลโดยตรงเพื่อแก้ไขข้อมูล ซึ่งเปิดโอกาสให้แก้รายการได้โดยไม่ผ่านระบบและไม่ทิ้งร่องรอย กรณีเช่นนี้กระทบความน่าเชื่อถือของข้อมูลในภาพรวม ไม่ใช่เฉพาะกระบวนการใดกระบวนการหนึ่ง
ผลกระทบที่สามเกี่ยวข้องกับบริษัทที่เตรียมเข้าจดทะเบียน เพราะแบบประเมินความเพียงพอของระบบการควบคุมภายใน ของสำนักงาน ก.ล.ต. มีคำถามในส่วนกิจกรรมการควบคุมที่ครอบคลุมการควบคุมทั่วไปด้านเทคโนโลยี การตอบว่ามีระบบและมีนโยบายเป็นเพียงจุดเริ่มต้น สิ่งที่ตรวจกันจริงคือมีหลักฐานว่าการควบคุมนั้นทำงานสม่ำเสมอตลอดงวดหรือไม่ ซึ่งเป็นคนละเรื่องกับการมีเอกสารนโยบายที่เขียนไว้ดี
ข้อควรระวัง จากประสบการณ์ที่พบเจอ
การทบทวนสิทธิผู้ใช้เป็นการควบคุมที่มีอยู่ในกระดาษมากที่สุดและมีประสิทธิผลน้อยที่สุด รูปแบบที่พบบ่อย คือ การส่งรายชื่อผู้ใช้ให้หัวหน้าฝ่ายเซ็นรับรอง แล้วหัวหน้าฝ่ายเซ็นคืนมาทั้งชุดโดยไม่ได้อ่าน
การทบทวนที่ใช้ได้จริงต้องแสดงให้เห็นว่ามีการเปรียบเทียบสิทธิกับหน้าที่ปัจจุบัน และต้องมีผลลัพธ์ปรากฏ เช่น มีรายการที่ถูกสั่งถอนสิทธิ ถ้าทบทวนทุกไตรมาสแล้วไม่เคยมีการเปลี่ยนแปลงใดเลยติดต่อกันหลายรอบ นั่นคือสัญญาณว่าการควบคุมไม่ได้ทำงาน
บัญชีของผู้ให้บริการภายนอกและผู้พัฒนาระบบเป็นจุดบอดที่พบเกือบทุกงาน หลายองค์กรเปิดสิทธิระดับสูงให้ผู้พัฒนาไว้ตั้งแต่ตอนติดตั้งระบบ แล้วไม่เคยปิด ทั้งที่โครงการจบไปหลายปีแล้ว ควรจัดทำทะเบียนบัญชีของบุคคลภายนอกแยกต่างหาก กำหนดวันหมดอายุ และทบทวนถี่กว่าบัญชีพนักงานทั่วไป
องค์กรขนาดกลางมักติดปัญหาเรื่องการแยกหน้าที่เพราะฝ่ายไอทีมีคนไม่กี่คน ในกรณีนี้อย่าพยายามเขียนรายงานว่าแยกหน้าที่ได้ครบถ้วนทั้งที่ทำไม่ได้จริง แนวทางที่ยอมรับได้คือยอมรับข้อจำกัดอย่างตรงไปตรงมา แล้วออกแบบการควบคุมชดเชย เช่น ให้ผู้บริหารที่อยู่นอกฝ่ายไอทีสอบทานบันทึกการเข้าใช้สิทธิสูงตามรอบ และเก็บหลักฐานการสอบทานนั้นไว้ การควบคุมชดเชยที่มีหลักฐานจริงน่าเชื่อถือกว่ารายงานที่สวยแต่ไม่ตรงกับข้อเท็จจริง
เรื่องที่พบบ่อยและแก้ยากที่สุดคือการใช้ไฟล์คำนวณภายนอกระบบมาสนับสนุนตัวเลขในงบการเงิน เช่น การคำนวณค่าเผื่อหนี้สงสัยจะสูญ การคำนวณผลประโยชน์พนักงาน หรือการปันส่วนต้นทุน ไฟล์เหล่านี้อยู่นอกขอบเขต ITGC ของระบบหลัก แต่มีผลต่อตัวเลขโดยตรง ควรกำหนดให้มีการควบคุมขั้นต่ำ ได้แก่ การจำกัดสิทธิแก้ไข การล็อกสูตร การสอบทานโดยผู้ที่ไม่ใช่ผู้จัดทำ และการเก็บเวอร์ชันที่ใช้ปิดงบ
สุดท้าย อย่าประเมิน ITGC จากขนาดขององค์กรหรือความทันสมัยของระบบ ระบบ ERP ราคาสูงที่ตั้งค่าสิทธิแบบเปิดกว้างเพื่อให้ทำงานสะดวก มีความเสี่ยงมากกว่าระบบสำเร็จรูปราคาย่อมเยาที่บังคับเส้นทางการอนุมัติไว้แน่นหนา สิ่งที่ต้องดูคือการตั้งค่าที่ใช้จริง ไม่ใช่ความสามารถที่ระบบมี
บทความนี้เรียบเรียงจากมาตรฐานการสอบบัญชี รหัส 315 (ปรับปรุง 2564) กรอบ COSO และมาตรฐาน ISAE 3402 ณ ปี 2569 รายการหลักฐานและข้อควรระวังในบทความเป็นแนวทางของผู้เขียน องค์กรควรปรับให้เข้ากับระบบงาน ขนาดกิจการ และข้อกำหนดของหน่วยงานกำกับดูแลที่เกี่ยวข้อง แนะนำให้ตรวจสอบมาตรฐานฉบับล่าสุดที่สภาวิชาชีพบัญชี (tfac.or.th) ก่อนนำไปใช้
