สารบัญ
ผมเพิ่งเข้าใจว่า Section 1.8 ไม่ใช่บทเรียนเรื่องเครื่องมือ — มันคือบทเรียนเรื่อง วิวัฒนาการของบทบาท auditor ตามเทคโนโลยีที่เปลี่ยน
ตอนผมอ่านรอบแรก ผมรู้สึกว่ามันมี alphabet soup เต็มไปหมด — CAATs, GAS, SCARF, ITF, CAS, EAM ทุกชื่อขึ้นต้นคล้ายๆ กัน ทำอะไรก็ฟังดูคล้ายๆ กัน ผมท่องไม่ไหวครับ จนกระทั่งวันนึงนั่งคุยกับ AI ช่วยอธิบายแล้วถึงเห็นว่า มันแบ่งเป็น 3 generations ตามยุค Manual → CAATs → Continuous + AI/ML แต่ละ generation คือคำตอบของคำถามที่ generation ก่อนหน้าตอบไม่ได้
ที่กระทบใจผมเป็นพิเศษคือบทบาทของ AI ตรงท้ายบทครับ ITAF 5th edition (กุมภาพันธ์ 2026) เพิ่งเพิ่ม section ของ AI ใน IS audit เข้ามา — แปลว่าตอนผมสอบจริง คำถามเกี่ยวกับ AI bias, training data validation, human interpretation จะเริ่มออกแน่นอน ในมุมส่วนตัวผมรู้สึกว่านี่ไม่ใช่แค่ exam topic — มันคือคำถามว่า ในยุคที่ AI ตัดสินใจแทนคนได้แล้ว ใครจะตรวจ AI และคำตอบของ ISACA คือ “auditor ยังต้องเป็นคนตัดสิน” ซึ่งผมเห็นด้วย
บันทึกตอนนี้เลยจะปูทั้ง 3 generations เรียงตามเวลา ให้เห็นว่าชื่อยากๆ ทุกอันมีที่อยู่ของมัน
Recap: เก็บ Evidence แบบ Manual ทันมั้ย?
ใน ตอน 09 เราคุยเรื่อง sampling — ตรวจตัวอย่างเพราะตรวจหมดไม่ได้ ใน ตอน 10 เราคุยเรื่องเก็บ evidence ที่ใช้ได้ เน้นที่ quality ของ evidence
แต่ลองคิดดูครับ ถ้าธนาคารมี 10 ล้าน transaction ต่อวัน ตรวจ sample 100 รายการ → ได้ evidence แค่ 100 / 10,000,000 = 0.001% ของ population
ถ้าเราตรวจได้ ทั้ง 10 ล้าน เลยล่ะ? confidence ของ audit opinion ก็จะแข็งแรงกว่าเยอะ
นี่คือสิ่งที่ data analytics เข้ามาเปลี่ยน Section 1.8 เลยเล่าเรื่อง วิวัฒนาการของเครื่องมือ audit ที่ทำให้สิ่งนี้เป็นไปได้
วิวัฒนาการ: 3 Generations ของ Audit Tools
ก่อนเข้าเนื้อขอวางภาพใหญ่ก่อน — เครื่องมือ audit พัฒนามา 3 generations:
Generation 1: Manual sampling ├── ตรวจเอกสารด้วยมือ └── เครื่องคิดเลขสำหรับคำนวณซ้ำ ↓Generation 2: CAATs (Computer-Assisted Audit Techniques) ├── ใช้ software ช่วยอ่าน + วิเคราะห์ data ├── ทำ full-population analysis ได้ └── แต่ยังเป็น "auditor รัน tool ตามจังหวะ" ↓Generation 3: Continuous Auditing + AI/ML ├── Audit ฝังในระบบ ตรวจ real-time ตลอดเวลา ├── AI ค้นหา pattern ที่คนมองไม่เห็น └── บทบาท auditor เปลี่ยนเป็น tool designer + interpreterใน Section 1.8 เราจะคุยทั้ง 3 generations เพราะข้อสอบถามถึงหมด
Data Analytics Overview: 8 Use Cases
Data analytics ใน audit = ใช้เครื่องมือเลือก + วิเคราะห์ full data set เพื่อ model หรือ monitor key data ขององค์กร หาความผิดปกติหรือ variance
8 use cases ที่ ISACA กำหนด:
- ประเมิน operational effectiveness ของ control environment
- ดู effectiveness ของ procedures / controls ที่ปรับใหม่
- หา business process issues
- หา control weaknesses + non-adherence
- หา exceptions / unusual business rules
- Benchmark performance
- หาพื้นที่ที่ data quality ไม่ดี
- ทำ risk assessment ใน planning phase
Process ของ Data Analytics
ก่อนใช้ analytics ต้องเตรียมตัว:
- Set scope — กำหนด objective ของการวิเคราะห์, data source, ความน่าเชื่อถือ
- Identify + obtain data — ไปขอจากเจ้าของ data, ลองทดสอบ sample เล็กๆ ก่อน, แล้ว extract ออกมา
- Validate data — ดูว่า sufficient + reliable พอมั้ย
- Validate balances / categories — ตรวจว่ายอด balance + category reconcile กันมั้ย
- Reconcile unusual data — ถ้าเจอ data แปลกๆ สอบกลับไปที่ source
- Perform analysis — รัน script ที่เตรียมไว้ + ทำ analytical test
- Verify time period — เช็คว่า dataset ครอบคลุม time period ที่ต้องการมั้ย
- Verify all required fields — ดูว่า field ที่ต้องใช้มีครบมั้ย
- Document results — บันทึกผล
- Review results — ให้ qualified person review
- Preserve results — เก็บ worksheet, script, macro, data file ไว้
ทุกขั้นสำคัญ ถ้า data ไม่ valid ตั้งแต่ต้น analysis ที่ทำก็ได้แค่ “garbage in, garbage out”
ตัวอย่าง Use Cases ที่ทำได้
- เทียบ logical access files กับ HR employee master files (ใครยัง active ในระบบ เทียบกับใครออกไปแล้ว)
- เทียบ file library settings กับ change management system data (change ที่ deploy match กับที่ approve มั้ย)
- Match login กับ employee record หา physical security violation
- ตรวจ table / system configuration settings
- Test completeness ของ data migration
- หา logical security gap (เช่น วิเคราะห์ Active Directory + job description)
ทั้งหมดนี้ทำใน full population ไม่ใช่ sample
CAATs: Computer-Assisted Audit Techniques
CAATs = tools ที่ให้ IS auditor gather + analyze data ระหว่าง IS review
จำเป็นเมื่อระบบ IS มี hardware / software environment ต่างกัน, data structure ต่างกัน, record format ต่างกัน
5 ประเภท CAATs หลัก
1. Generalized Audit Software (GAS) — สำคัญที่สุด
GAS = software มาตรฐานที่อ่าน data จาก database platform ต่างๆ, flat-file system, ASCII format ได้
GAS ทำอะไรได้บ้าง?
ถ้าจะแบ่งเป็น 2 มุม — มุม “เข้าถึง + จัด data” กับ มุม “วิเคราะห์เชิง audit”:
มุมแรก คือการ get data ออกมาแล้วจัดให้พร้อมใช้:
- Data queries — ตั้ง filter ตามเงื่อนไข + อ่าน file structure ที่ต่างกันได้
- File reorganization — indexing, sorting, merging, linking ข้าม file
- Data selection — กรอง record ที่เข้าเงื่อนไขทั้ง dataset (global filtration)
มุมที่สอง คือ ใช้ data ที่ได้มาทดสอบหา signal ที่ auditor สนใจ:
- Statistical functions — sampling, stratification (แบ่งชั้น population), frequency analysis
- Arithmetical functions — math computation + recomputation (เช็คยอดที่บริษัทคำนวณว่าตรงมั้ย)
- Sequence checking — ตรวจว่าเลข transaction/document มาเรียงต่อเนื่องไหม ขาดตัวไหน
- Duplicate checking — หา record ซ้ำ (เช่น invoice number ซ้ำ = อาจเป็น double-billing)
ทำไมถึง independent: GAS ไม่ต้องพึ่ง tools ของ auditee → IS auditor มี independent data access หาเจอเองโดยไม่ต้องพึ่งคนถูกตรวจ
2. Utility Software
- Report generator จาก DBMS
- Provides evidence ของ system control effectiveness
3. Test Data
- IS auditor ใช้ sample data ทดสอบ program logic
- ดูว่า program ทำงานตาม objectives มั้ย
4. Application Software Tracing + Mapping
- ตาม processing path ที่วิ่งผ่าน application
5. Expert Systems
- ให้ audit direction + information จาก knowledge base ของ senior auditor
CAATs ใช้ทำอะไรได้บ้าง?
ครอบคลุมงาน audit แทบทุกแบบ — ไล่จากระดับ transaction ถึง system security:
- Test ของ transaction / balance detail — ตรวจรายละเอียดของรายการทีละตัว (เช่น เช็คทุก journal entry ว่าผ่าน approval ครบไหม)
- Analytical review procedures — วิเคราะห์ trend / ratio / outlier เพื่อหา anomaly
- Compliance test ของ IS general controls — ทดสอบ control ระดับองค์กร (access management, change management)
- Compliance test ของ IS application controls — ทดสอบ control ระดับ application (input validation, calculation accuracy)
- Network + OS vulnerability assessment — สแกนหา vulnerability ของ infrastructure
- Penetration testing — ลองโจมตีระบบเองดูว่าเจาะได้รึเปล่า
- Application security testing + source code scan — ตรวจ code ว่ามี security flaw มั้ย
Implementation Considerations (Checklist ก่อน Deploy)
ก่อน deploy CAATs จริง auditor ต้องตอบคำถาม 3 มุมให้ได้ครบ:
มุม “ใช้ง่ายมั้ย”:
- Ease of use — auditor ทั่วไปเรียนรู้ใช้ได้ในเวลาที่สมเหตุสมผลมั้ย
- Training requirements — ต้องลงทุนเวลา/เงิน train ทีมเท่าไหร่
- Flexibility of uses — รองรับ scenario audit หลายแบบได้มั้ย หรือทำได้แค่อย่างเดียว
- Reliability ของ software — เคย crash เคย fail ตอน critical run มั้ย
มุม “deploy ที่ auditee ได้มั้ย”:
- Installation requirements — ลงที่ไหน ใช้ resource เท่าไหร่
- Permission to install on auditee servers — auditee ยอมให้ลงระบบเค้ามั้ย หรือต้องรันที่ฝั่งเรา
- Processing efficiencies — รัน analysis ภายในเวลาที่ engagement กำหนดได้มั้ย
- Complexity ของ coding + maintenance — script ที่เขียนแล้ว maintain ต่อยากแค่ไหน
มุม “data ที่เข้ามาเชื่อถือได้มั้ย”:
- Effort to bring source data into tools — extract + load data ใช้แรงเท่าไหร่
- Integrity ของ imported data — ตรวจได้มั้ยว่า import มาครบไม่บิดเบือน
- Time stamp ของ downloaded data — รู้แน่ชัดมั้ยว่า snapshot นี้ถ่ายเมื่อไหร่
- Confidentiality ของ data — ระหว่างที่ data อยู่ในมือ auditor security level พอมั้ย
กฎสำคัญ: CAATs Data Access
IS auditor ควรขอ READ-ONLY access ต่อ production data ส่วน manipulation ทั้งหมดให้ทำบน copies of production data ไม่ใช่ทำบน production ตรงๆ
ถ้า auditor ทำ analysis บน production แล้วเผลอเปลี่ยน data → disaster — auditor กลายเป็น “agent of change” บน production = ผิด independence + อาจเสียหายทางธุรกิจ
Continuous Auditing + Monitoring
Continuous auditing = IS auditor ประเมินแบบ ongoing โดยไม่กระทบ operations
มีค่ามากในสภาพแวดล้อมที่:
- Transaction volume สูง
- Paper trail น้อยหรือไม่มี
- ต้องลด time lag ระหว่าง misuse กับ detection
5 Continuous Auditing Techniques (เรียงตาม Complexity)
1. SCARF / EAM (Systems Control Audit Review File / Embedded Audit Modules) — Complexity: Very High
- ฝัง audit software ใน host application system ขององค์กร
- คงไว้ใน application แบบ selective
- ใช้เมื่อ: ขัดจังหวะ regular processing ไม่ได้
2. Snapshots — Complexity: High
- ถ่าย “ภาพ” ของ processing path ที่ transaction วิ่งผ่านตั้งแต่ input → output
- ติด tag identifier ให้ transaction
- ใช้เมื่อ: ต้องการ audit trail
3. Audit Hooks — Complexity: Medium
- ฝัง audit flag ใน application system ให้เป็น early warning red flag
- ใช้เมื่อ: ต้องการ audit เฉพาะ transaction / process บางอย่าง
4. ITF (Integrated Test Facility) — Complexity: Low
- ตั้ง dummy entity ใน production file
- ปล่อย test transaction เข้าไปพร้อม live transaction
- เทียบ output กับผลที่คำนวณแยกอย่างอิสระ
- ใช้เมื่อ: วิธีอื่นไม่คุ้ม
5. CAS (Continuous and Automated Simulation) — Complexity: Medium
- จำลอง instruction execution ขณะที่ transaction ถูกใส่เข้ามา
- ดูว่า transaction เข้า predetermined criteria มั้ย
- ใช้เมื่อ: ต้องตรวจ transaction ที่เข้าเกณฑ์เฉพาะ
Continuous Auditing Advantages
- จับ control problem ตอนเกิด (ไม่ใช่หลายเดือนหลังจากนั้น)
- ป้องกัน negative effect ก่อนที่จะสะสม
- ลด delay, time constraint, error ที่เจอช้า
Challenges ที่ต้องระวัง
- ต้องมี full top management support
- ต้องมี extensive technical knowledge
- False positive + false negative ต้องคุมให้น้อยที่สุด
- อาจต้อง fine-tune auditing layer เป็นระยะ
Tools ที่ใช้
- Query tool + process/data analysis — ตัวกลางที่ดึง + แปลง data ออกมาให้ analyze
- DBMS, data warehouse, data mart, data mining — โครงสร้าง data ที่ enterprise ใช้กันแพร่หลาย
- Social network technologies — สำหรับ analyze pattern ที่ฝังใน relational data
- XBRL (Extensible Business Reporting Language) — มาตรฐานสำหรับ financial reporting ที่ machine-readable
AI/ML in IS Audit (Generation 3)
ITAF 5th edition (กุมภาพันธ์ 2026) เพิ่งเพิ่ม section ของ AI ใน IS audit เข้ามา — เป็นเรื่องใหม่ที่ exam จะเริ่มถามมากขึ้น
Algorithms คืออะไร?
Algorithm = ชุดขั้นตอนที่กำหนดไว้สำหรับ process หนึ่งๆ ไม่ใช่ทุก algorithm จะซับซ้อน บางอันเป็นแค่ “if / then” logic
AI / ML techniques คือ evolution ของ CAATs — ข้อพิจารณาเดียวกัน apply ได้:
- Read-only access
- Validate data
- Document ทุกอย่าง
- Human review ผลที่ได้
6 AI/ML Audit Applications
| Technique | ทำอะไร | Use ใน Audit |
|---|---|---|
| Document classification | จัด documents เข้า topics | เข้าใจ SOPs, infer จาก prior audit reports |
| Text summarization | สร้าง natural language summary | จัดรูปแบบ audit observations |
| Topic analysis | ระบุ topics ใน documents | วิเคราะห์ data, สร้าง keyword rule engines |
| Search and retrieval | หา documents ตรง search criteria | ค้นหา similar audit report references |
| Statistical analysis | ประเมิน trends ของ terms/phrases/topics | aggregate data, ระบุ trends |
| Sentiment analysis | สกัด + วิเคราะห์ text sentiment | ระบุ key issues + risk, prepare reports |
AI / ML Risks ที่ต้องระวัง
นี่คือส่วนที่สำคัญที่สุด ถ้าใช้ AI ผิดวิธี = อันตรายกว่าไม่ใช้
- Training data ต้อง validate — ทั้งตอน implement และทำเป็นระยะ
- Numerical significance ต้องเข้าใจ — ผลต้อง represent ทั้ง audit universe ไม่ใช่แค่บางส่วน
- Conclusion ต้องอิง substantive evidence — ไม่ใช่แค่ algorithm output
- AI tools ที่ human สร้าง = มี ethics + bias risks — judgment + stereotype ของผู้สร้างฝังเข้าไปด้วย
- Training data ต้องครอบคลุม usual + unusual cases — ไม่งั้น AI จะ miss edge case
- ต้องมี human interpretation เสมอ — AI ไม่เคยเป็น final word
Bias in AI Auditing — กรณีจริง
ถ้า AI tool ของ auditor ถูก train บน biased data ผลลัพธ์อาจ flag transaction ของ กลุ่มคนบางกลุ่มมากกว่าปกติ โดยไม่มีเหตุผลที่ valid
ในบริบทธุรกิจ อาจมี implication ทางกฎหมายเรื่อง discrimination ถ้า audit recommendation นำไปสู่การปฏิเสธบริการ
หลักการของ ISACA — AI = tool ไม่ใช่ decision-maker auditor ยังเป็นคนตัดสินและรับผิดชอบ professional opinion
Trap Patterns ที่ Exam ออก
| Trap | ความเข้าใจผิด | ความเข้าใจที่ถูก |
|---|---|---|
| CAATs replace IS auditor | คิดว่า CAATs ทำ audit อัตโนมัติทั้งหมด | CAATs = tools — IS auditor design + interpret + judgment |
| Continuous = always better | คิดว่า continuous auditing แทน periodic ได้ทั้งหมด | Continuous = setup cost สูง; periodic ยังเหมาะกับบาง engagements |
| SCARF = simplest | คิดว่า embedded modules = simple | SCARF = Very High complexity; ITF = Low complexity |
| AI = perfect | คิดว่า ML results objective + error-free | ML ต้อง human interpretation + training data biases ทำให้ผิดได้ |
| Test data on production | คิดว่า CAATs ใช้ test data บน production system | Manipulations ต้องทำบน copies ของ production — ห้ามแตะ production direct |
| GAS = financial only | คิดว่า GAS เป็น accounting software | GAS อ่านจาก database platforms ต่างๆ + flat files + ASCII |
Cross-Reference
- Sampling vs. Full Population — analytics เข้ามาแทนบางส่วนของ sampling จาก ตอน 09
- Analytics output = evidence — ต้องผ่านมาตรฐาน sufficient + competent จาก ตอน 10
- CAATs ใน Audit Program — testing methodology ที่ระบุใน audit program จาก ตอน 08
- Continuous monitoring + IT Operations — Domain 4 จะลงลึก continuous monitoring ในระบบ IT operations
สิ่งที่ผมเก็บได้จากบทนี้
ในมุมผม สิ่งที่ Section นี้สอนจริงๆ ไม่ใช่ชื่อ tools แต่คือ mindset ว่า auditor ต้องรู้จักเครื่องมือมากแค่ไหนถึงจะตรวจคนที่ใช้เครื่องมือนั้นได้ ครับ ถ้าบริษัทใช้ AI ตัดสินใจ แล้ว auditor ไม่เข้าใจ AI ทำงานยังไง ก็ตรวจไม่ได้ — แค่ “ดูว่ามี AI” ไม่พอ ต้องเข้าใจถึงระดับ training data, bias, model lifecycle
ที่ผมคิดว่าจะติดอยู่ในใจไปนานคือกฎ Read-Only access บน production ครับ ฟังดูเหมือนกฎเทคนิค แต่จริงๆ เป็นกฎเรื่อง independence — ถ้า auditor แตะ production data ได้ auditor ก็เป็น “agent of change” และเสียความเป็นอิสระทันที กฎเทคนิคที่ปกป้องหลักการ governance ใหญ่ๆ ของวิชาชีพอยู่ข้างหลัง — ตรงนี้เท่ที่สุดของวิชา audit สำหรับผม
สิ่งที่ผมจดสำหรับวันสอบคือ — SCARF complexity สูง ไม่ใช่ต่ำ; ITF complexity ต่ำ; AI ≠ decision-maker, auditor คือคนตัดสินอยู่ดี; Manipulations ต้องทำบน copies ห้ามแตะ production สี่อันนี้ผูกกัน trap ในบทนี้ส่วนใหญ่ก็ตามกฎเหล่านี้
บทถัดไป — พอ test เสร็จ + evidence เก็บครบ + analytics รันแล้ว → ขั้นต่อไปคือ “ออก report” ซึ่งจริงๆ ไม่ใช่แค่เขียน มันมี objective + structure + audience ที่ต้องเข้าใจ
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 1: Section 1.8 Audit Data Analytics
