ใน Part 0001 เราได้ทำความเข้าใจภาพรวมของ IT Audit รวมถึงความแตกต่างและความเชื่อมโยงระหว่าง IT General Controls (ITGC) กับ Application Controls กันแล้ว สำหรับ Part 0002 ซึ่งเป็นตอนจบ เราจะต่อยอดให้ครบสองเรื่อง คือ “ผู้ตรวจสอบตรวจอย่างไร” และ “องค์กรได้อะไรจากการตรวจสอบ” พร้อมเจาะตัวอย่าง ITGC แต่ละด้านให้เห็นภาพมากขึ้นครับ อ่าน Part 0001
แนวทางของ The IIA (สมาคมผู้ตรวจสอบภายใน) อธิบายว่างานตรวจสอบต้องมีการวางแผน ดำเนินงานเพื่อพัฒนาข้อตรวจพบและข้อสรุป สื่อสารผล และติดตามแผนการแก้ไข ขณะที่ ISACA ใช้ภาพของกระบวนการที่ประกอบด้วยช่วงเตรียมการ วางแผน ลงพื้นที่ และรายงานผล[1][2]
1. ITGC แต่ละด้าน ผู้ตรวจสอบมองหาอะไร?
FISCAM 2024 จัดกลุ่มการควบคุมทั่วไปไว้ 5 ด้าน ได้แก่ Security Management, Access Controls, Segregation of Duties, Configuration Management และ Contingency Planning อย่างไรก็ตาม ขอบเขตการตรวจสอบไม่จำเป็นต้องครอบคลุมทุกด้านเสมอไป แต่เลือกตามวัตถุประสงค์ ระบบที่เกี่ยวข้อง และระดับความเสี่ยงของงานตรวจสอบ[3]
| กลุ่ม ITGC | คำถามด้านความเสี่ยง | ตัวอย่างหลักฐานที่อาจตรวจสอบ |
| Security Management | องค์กรมีผู้รับผิดชอบ นโยบาย การประเมินความเสี่ยง และการติดตามประเด็นด้านความมั่นคงปลอดภัยที่ชัดเจนหรือไม่ | นโยบาย/มาตรฐาน, Risk Register, รายงานประชุม, แผนปรับปรุง, ตัวชี้วัดและรายงานติดตาม |
| Access Controls | ผู้ใช้ได้รับสิทธิที่ถูกต้อง ในช่วงเวลาที่เหมาะสม และสิทธิถูกยกเลิกหรือทบทวนเมื่อหน้าที่เปลี่ยนหรือไม่ | คำขอสิทธิ, รายชื่อผู้ใช้, Privileged Access, Access Review, Authentication/Access Logs |
| Segregation of Duties | มีหน้าที่หรือสิทธิที่ขัดแย้งกันจนบุคคลเดียวสามารถทำรายการสำคัญได้ตั้งแต่ต้นจนจบหรือไม่ | ผังองค์กร, RACI/Role Matrix, รายชื่อสิทธิพิเศษ, Conflict Report, Compensating Controls |
| Configuration Management | การพัฒนา เปลี่ยนแปลง ตั้งค่า นำระบบขึ้นใช้งาน และแก้ไขช่องโหว่ผ่านการอนุมัติและทดสอบอย่างเหมาะสมหรือไม่ | Change Ticket, Approval, Test/UAT Evidence, Deployment Log, Baseline Configuration, Patch/Vulnerability Report |
| Contingency Planning | เมื่อระบบหยุดชะงัก องค์กรสามารถสำรอง กู้คืน และให้บริการต่อได้ตามความต้องการทางธุรกิจหรือไม่ | Backup Report, Restore Test, BCP/DRP, ผลการซ้อม, RTO/RPO, Lessons Learned |
รายการในตารางเป็นตัวอย่างเพื่อให้เห็นมุมมองของผู้ตรวจสอบ ไม่ใช่ Checklist สำเร็จรูป เพราะหลักฐานและวิธีทดสอบต้องออกแบบให้สอดคล้องกับระบบ กระบวนการ และความเสี่ยงจริงของแต่ละองค์กรครับ
2. กระบวนการ IT Audit โดยทั่วไป
แม้แต่ละองค์กรจะมีระเบียบวิธีตรวจสอบแตกต่างกัน แต่ภาพรวมของงานมักเดินจากการกำหนดวัตถุประสงค์และความเสี่ยง ไปสู่การเก็บหลักฐาน ประเมินผล สื่อสารข้อสรุป และติดตามการแก้ไข โดยกระบวนการต้องย้อนกลับไปทบทวนขั้นก่อนหน้าได้เมื่อพบข้อมูลใหม่[1][2]
| ขั้นตอน | ผู้ตรวจสอบทำอะไร | ผลลัพธ์ที่ได้ |
| 1. วางแผนและกำหนดขอบเขต | ทำความเข้าใจวัตถุประสงค์ทางธุรกิจ กระบวนการ ระบบ ข้อมูล ผู้เกี่ยวข้อง และความเสี่ยง พร้อมกำหนด Objective, Scope, Criteria และ Work Program | แผนงานตรวจสอบที่ตอบคำถามชัดว่า “ตรวจเรื่องอะไร เพื่ออะไร และใช้เกณฑ์ใด” |
| 2. ทำความเข้าใจและประเมินการออกแบบ | สัมภาษณ์ ทำ Walkthrough อ่านเอกสาร และไล่ Data Flow เพื่อระบุความเสี่ยงและการควบคุม จากนั้นประเมินว่าการควบคุมออกแบบมาเพื่อลดความเสี่ยงได้เหมาะสมหรือไม่ | Process Flow, Risk and Control Matrix (RCM), จุดควบคุมสำคัญ และแนวทางทดสอบ |
| 3. เก็บหลักฐานและทดสอบการปฏิบัติจริง | ตรวจเอกสาร สังเกตการณ์ สอบทานรายงานและ Log สุ่มตัวอย่าง ทดสอบซ้ำ หรือใช้ Data Analytics เพื่อดูว่าการควบคุมถูกนำไปใช้และทำงานอย่างสม่ำเสมอหรือไม่ | หลักฐานการทดสอบและข้อสรุปต่อการควบคุมแต่ละรายการ |
| 4. ประเมินข้อตรวจพบและสรุปผล | เปรียบเทียบสภาพที่พบกับเกณฑ์ วิเคราะห์สาเหตุ ผลกระทบ ความเป็นไปได้ และความสำคัญ รวมทั้งพิจารณาผลรวมของข้อตรวจพบ | Audit Finding, ระดับความสำคัญ และ Engagement Conclusion |
| 5. รายงานผลและติดตามการแก้ไข | สื่อสารวัตถุประสงค์ ขอบเขต ข้อตรวจพบ ข้อสรุป และแผนดำเนินการที่ตกลงกับผู้รับผิดชอบ จากนั้นติดตามและยืนยันผลตามระดับความเสี่ยง | รายงานตรวจสอบ, Action Plan, Owner, Due Date และสถานะ Follow-up |
3. หลักฐานแบบไหนจึงใช้สรุปผลได้?
The IIA กำหนดให้ข้อมูลที่ใช้วิเคราะห์และประเมินต้องมีความเกี่ยวข้องกับวัตถุประสงค์ของงาน มีความน่าเชื่อถือ และเพียงพอที่จะรองรับข้อตรวจพบและข้อสรุป ผู้ตรวจสอบจึงไม่ควรพึ่งหลักฐานชิ้นเดียวโดยอัตโนมัติ แต่ต้องพิจารณาแหล่งที่มา ช่วงเวลา ความครบถ้วน และความสามารถในการตรวจสอบย้อนกลับ[1]
| ประเภทหลักฐาน | ตัวอย่าง | ข้อควรพิจารณา |
| เอกสารและบันทึก | นโยบาย ขั้นตอน Ticket รายงานประชุม สัญญา แบบฟอร์มอนุมัติ | เอกสารประกาศใช้จริงหรือไม่ เป็นปัจจุบัน และสอดคล้องกับการปฏิบัติหรือไม่ |
| รายงานจากระบบและ Log | User List, Audit Log, Change Log, Backup Report, Configuration Report | รายงานดึงจากแหล่งใด มี Filter อะไร และระบบต้นทางมีการควบคุมเพียงพอหรือไม่ |
| การสัมภาษณ์และ Walkthrough | ให้เจ้าของกระบวนการสาธิตขั้นตอนตั้งแต่ต้นจนจบ | ใช้เพื่อเข้าใจวิธีทำงาน และควรยืนยันด้วยหลักฐานอื่นเมื่อเป็นประเด็นสำคัญ |
| การสุ่มตัวอย่างและทดสอบซ้ำ | ตรวจรายการตามช่วงเวลา หรือ Reperform การคำนวณ/การอนุมัติ | ตัวอย่างต้องเหมาะกับประชากรและความเสี่ยง ไม่เลือกเฉพาะรายการที่สะดวก |
| Data Analytics | วิเคราะห์ผู้ใช้ที่ไม่เคลื่อนไหว สิทธิขัดแย้ง Change นอกเวลา หรือรายการผิดปกติ | ช่วยตรวจทั้งประชากรหรือกลุ่มเป้าหมายได้ แต่ต้องตรวจสอบคุณภาพและความครบถ้วนของข้อมูล |
4. เมื่อพบปัญหา ข้อตรวจพบควรตอบอะไรบ้าง?
มาตรฐานนิยาม Finding ว่าเป็นช่องว่างระหว่างเกณฑ์ที่ควรเป็นกับสภาพที่พบ และให้ผู้ตรวจสอบประเมินสาเหตุเมื่อสามารถระบุได้ ผลกระทบ และความสำคัญของประเด็น ในการเขียนรายงานจึงมักจัดเนื้อหาให้ผู้อ่านตอบคำถามต่อไปนี้ได้[1]
| องค์ประกอบ | คำถามที่ต้องตอบ |
| Criteria — เกณฑ์ | สิ่งที่ควรเป็นคืออะไร อ้างอิงจากนโยบาย มาตรฐาน กฎหมาย สัญญา หรือ Control Design ใด |
| Condition — สภาพที่พบ | ตรวจพบอะไร ที่ไหน เมื่อใด และหลักฐานรองรับคืออะไร |
| Root Cause — สาเหตุ | เหตุใดช่องว่างจึงเกิดขึ้น เช่น กระบวนการไม่ชัด ระบบไม่รองรับ ทรัพยากรไม่เพียงพอ หรือการติดตามไม่ต่อเนื่อง |
| Effect / Risk — ผลกระทบหรือความเสี่ยง | เหตุการณ์ใดอาจเกิดขึ้น มีผลต่อเป้าหมาย ข้อมูล บริการ กฎหมาย ลูกค้า หรือชื่อเสียงอย่างไร |
| Recommendation / Action Plan | จะจัดการความเสี่ยงอย่างไร ใครรับผิดชอบ และจะแล้วเสร็จเมื่อใด |
5. ตัวอย่าง : Change Management ของระบบงานสำคัญ สมมติว่าระบบคำนวณวงเงินทำงานถูกต้องตามเงื่อนไขของธุรกิจ แต่ทีมพัฒนามีสิทธิแก้ไขโปรแกรมบน Production ได้ตลอดเวลา ประเด็นนี้แสดงให้เห็นว่าความน่าเชื่อถือของ Application Controls ยังพึ่งพา ITGC ด้าน Access Controls, Segregation of Duties และ Configuration Management อยู่ครับ
| หัวข้อ | ตัวอย่าง |
| Criteria | การเปลี่ยนแปลงระบบ Production ต้องผ่านการอนุมัติ การทดสอบ และการนำขึ้นใช้งานโดยบุคคลที่ได้รับมอบหมายตามขั้นตอนขององค์กร |
| Condition | พบว่าผู้พัฒนา 3 รายมีสิทธิถาวรบน Production และมีการนำ Change ขึ้นใช้งานบางรายการโดยไม่พบหลักฐานอนุมัติจากผู้มีอำนาจ |
| Root Cause | ทีมมีขนาดเล็กและยังไม่มี Deployment Process ที่แยกหน้าที่หรือบังคับ Approval ผ่านเครื่องมือ |
| Effect / Risk | อาจเกิดการแก้ไขที่ไม่ได้รับอนุมัติหรือไม่ผ่านการทดสอบ ส่งผลต่อความถูกต้องของผลลัพธ์ ความพร้อมใช้ และความสามารถในการตรวจสอบย้อนหลัง |
| Action Plan | ยกเลิกสิทธิถาวรของผู้พัฒนา ใช้ Controlled Deployment/CI-CD ที่บังคับ Approval จัดทำ Emergency Access และทบทวน Deployment Log เป็นระยะ |
6. แล้วองค์กรได้อะไรจาก IT Audit?
ผลของ IT Audit ไม่ได้มีเพียงรายการข้อบกพร่อง แต่ควรช่วยให้ผู้บริหารและเจ้าของกระบวนการมองเห็นทั้งจุดแข็ง ช่องว่าง และลำดับความสำคัญของความเสี่ยง เพื่อนำไปตัดสินใจและปรับปรุงการควบคุมได้อย่างมีเหตุผล[1][4]
- ความเชื่อมั่นอย่างสมเหตุสมผล — เพิ่มความมั่นใจว่าการกำกับดูแล ความเสี่ยง และการควบคุมในขอบเขตที่ตรวจได้รับการออกแบบและดำเนินการอย่างเหมาะสม
- ภาพความเสี่ยงที่ชัดขึ้น — เชื่อมโยงประเด็นทางเทคนิคกับผลกระทบต่อธุรกิจ ลูกค้า กฎหมาย ข้อมูล และความต่อเนื่องของบริการ
- แผนดำเนินการที่รับผิดชอบได้ — ระบุผู้รับผิดชอบ แนวทางแก้ไข และกำหนดเวลา พร้อมติดตามผลตามความสำคัญของประเด็น
- การยืนยันจุดแข็ง — รายงานสามารถรับรู้การควบคุมที่มีประสิทธิผล ไม่ได้กล่าวถึงเฉพาะข้อบกพร่อง
- การปรับปรุงอย่างต่อเนื่อง — ข้อมูลจากหลายงานตรวจสอบช่วยให้เห็น Root Cause หรือประเด็นซ้ำ และนำไปปรับกระบวนการในระดับองค์กรได้
สรุป Part 0002 และจบซีรีส์
- ITGC 5 ด้านช่วยให้ผู้ตรวจสอบมองความเสี่ยงระดับสภาพแวดล้อม ได้แก่ Security Management, Access Controls, Segregation of Duties, Configuration Management และ Contingency Planning[3]
- กระบวนการตรวจสอบเริ่มจากความเสี่ยงและวัตถุประสงค์ เก็บหลักฐานที่เกี่ยวข้อง น่าเชื่อถือ และเพียงพอ ก่อนพัฒนา Finding, Conclusion และ Action Plan[1]
- คุณค่าของ IT Audit เกิดขึ้นเมื่อผลตรวจถูกสื่อสารอย่างเข้าใจง่าย ผู้บริหารตัดสินใจบนข้อมูล และแผนแก้ไขได้รับการติดตามจนลดความเสี่ยงได้จริง[4]
เมื่ออ่าน Part 0001 และ Part 0002 จบ ผู้อ่านจะเห็นภาพพื้นฐานว่า IT Audit คืออะไร ตรวจอะไร ตรวจอย่างไร และส่งมอบคุณค่าอะไรให้กับองค์กร ส่วนหัวข้อเชิงลึก เช่น Access Management, Change Management, Cybersecurity, Cloud, Data หรือ AI Audit สามารถแตกออกเป็นบทความเฉพาะเรื่องต่อไปได้ครับ
เอกสารอ้างอิง
[1] The Institute of Internal Auditors (IIA). Global Internal Audit Standards, 2024 Edition; Domain V: Performing Internal Audit Services, Standards 13.1-15.2 and Glossary. เปิดแหล่งข้อมูล
[2] ISACA. IT Audit Manager — responsibilities across pre-planning, planning, fieldwork, reporting, documentation, and issue resolution. เปิดแหล่งข้อมูล
[3] U.S. Government Accountability Office (GAO). Federal Information System Controls Audit Manual (FISCAM), 2024 Revision. เปิดแหล่งข้อมูล
[4] The Institute of Internal Auditors (IIA). Communicating Final Engagement Results, Global Practice Guide, 2025. เปิดแหล่งข้อมูล
หมายเหตุ: เนื้อหาเรียบเรียงและย่อความจากแหล่งอ้างอิงเพื่อใช้เป็นบทความความรู้เบื้องต้น ไม่ใช่คำแปลอย่างเป็นทางการของมาตรฐาน และตัวอย่างสถานการณ์เป็นกรณีสมมติ
