สารบัญ
Recap: Part A พาเรามาถึงไหน
Part A ที่เพิ่งจบ (ตอน 0 ถึง ตอน 07) เล่า “การเตรียมตัวก่อนลงสนาม” ครบทุกขั้น:
- รู้กฎที่ govern auditor (Standards / Guidelines / Tools / Code of Ethics / ITAF)
- รู้ว่าใครให้อำนาจมาตรวจ (Charter ที่ board อนุมัติ)
- เห็น flow ภาพใหญ่ของ IS audit (ตอน 03)
- เลือกประเภท audit ได้ (11 ประเภท + CSA + Integrated)
- พูดภาษา Risk + Control คล่อง (ตอน 05)
- วางแผนตรวจตาม risk (Audit Universe + 4-Layer Planning Hierarchy + Annual Plan)
- รู้ว่ากฎหมายเป็น mandatory input ใน planning
มาถึงตอนนี้ มี Annual Plan วางอยู่บนโต๊ะแล้ว — ระบุชัดว่า Q2 ต้องตรวจระบบ ERP ของฝ่าย Finance
คำถามต่อไป: แล้วยังไงต่อ? “ตรวจ” หมายความว่าอะไรในทางปฏิบัติ?
นี่คือสิ่งที่ Part B จะมาเล่า — และเริ่มที่บทนี้ด้วยภาพใหญ่ก่อนลงรายละเอียด
Audit Engagement = Project Management ประเภทหนึ่ง
ลองนึกถึงงานก่อสร้างตึก
งานก่อสร้างไม่ใช่แค่ “ช่างปูนมาเทคอนกรีต” — มันเป็น project ที่มีหลายขั้น: เขียนแบบ → วางแผน timeline → จัดทีม → ลงมือก่อ → ตรวจงาน → ส่งมอบ → repair รายการที่ลูกค้าชี้
audit engagement ก็เหมือนกันครับ — ไม่ใช่แค่ “ลงไปตรวจ” แต่เป็น project ที่มีหลายขั้น ที่ต้องบริหารทุก dimension ของ project management:
- Scope: จะตรวจอะไรบ้าง / ไม่ตรวจอะไร
- Time: เริ่มเมื่อไหร่ จบเมื่อไหร่ deliverable แต่ละชิ้นวันไหน
- Resource: ใครในทีมทำอะไร / ทักษะที่ต้องการ
- Quality: มาตรฐานวิชาชีพที่ต้องเป็นไปตาม
- Risk: ของ project เอง (ไม่ใช่ของ auditee) — engagement นี้มี risk อะไรบ้างที่อาจทำให้ส่งมอบไม่ทัน
ISACA กำหนด 4 เทคนิคของ project management สำหรับ audit project:
- Plan the engagement — พิจารณา risk เฉพาะของงาน
- Build the audit plan — แผน task ตาม timeline + ประเมิน resource ตามจริง
- Execute the plan — ทำตาม milestone
- Execute oversight — รายงาน actual vs. planned, จัดการ scope ให้อยู่ใน time/budget
มุม IS auditor ในการประเมิน project — มี 5 มิติที่ต้องดูเสมอ:
- Security — CIA triad (Confidentiality, Integrity, Availability)
- Quality — ประสิทธิผลและประสิทธิภาพ
- Fiduciary — compliance + ความน่าเชื่อถือ
- Service — บริการที่ user ได้รับ
- Capacity — ขีดความสามารถระบบ
3 Phases ของ Audit Engagement (spine ของ Part B)
ทุก audit engagement ดำเนินตาม 3 phases หลัก ที่แต่ละ phase มี output ส่งต่อให้ phase ถัดไป
Phase 1: Planning (เตรียมงาน) ↓Phase 2: Fieldwork + Documentation (ลงสนาม + บันทึก) ↓Phase 3: Reporting + Follow-up (ส่งมอบและติดตาม)มาดูทีละ phase ว่ามีอะไรบ้าง — แล้วทีเซอร์ว่าบทถัดไปจะเจาะลึกเรื่องอะไร
Phase 1: Planning (เตรียมงาน)
ขั้นนี้คือ “เปิด project” — ก่อนใครเดินไปคุยกับ auditee เลย
5 ขั้นตอน:
- Determine audit subject — กำหนดว่าจะตรวจพื้นที่ใด (ระบบ, function, location, ช่วงเวลา)
- Define audit objective — วัตถุประสงค์ของ audit ครั้งนี้คืออะไร
- Set audit scope — ขอบเขตชัดเจน: ระบบไหน function ไหน เข้าออกตรงไหน
- Perform preaudit planning — ประเมิน risk ของ engagement นี้, สัมภาษณ์ทีม, ระบุ regulatory requirements, จัดสรร resource, ระบุ communication plan
- Determine audit procedures + data gathering — กำหนดวิธีตรวจและข้อมูลที่ต้องใช้
Audit objectives ≠ Control objectives — ความต่างที่ exam ชอบถาม:
- Audit objective = “เป้าหมายของ audit ครั้งนี้” (เช่น “verify ว่า dollar-amount edits ถูก configure ในระบบ”)
- Control objective = “เป้าหมายของ control ที่กำลังถูกตรวจ” (เช่น “ป้องกันการป้อนค่าเงินผิดในระบบ”)
ทักษะที่ critical ของ IS auditor ในขั้นนี้: แปล broad audit objective → IS-specific audit objective ที่ทดสอบได้
Phase 2: Fieldwork + Documentation (ลงสนาม + บันทึก)
ขั้นนี้คือ “ทำงานจริง” — ใช้เวลาส่วนใหญ่ของ engagement
4 ขั้นตอน:
- Acquire data — ขอ evidence list, เก็บรวบรวมแบบ traceable
- Test controls — testing techniques: re-formatting, observation, inspection
- Discover and validate results — ระบุ deviation จากผลที่คาดหวัง
- Document results — บันทึกใน work papers ตาม standards
ใน Phase นี้มีคำถามใหญ่ 4 ข้อที่บทถัดๆ ไปจะตอบ:
- ทดสอบ controls ยังไง? เลือก sample เท่าไหร่ พอ? → ตอน 09 — Testing & Sampling
- เก็บ evidence ยังไงให้ใช้ได้? → ตอน 10 — Evidence Collection
- ใช้เครื่องมือ data analytics ช่วยได้มั้ย? → ตอน 11 — Data Analytics + CAATs + AI
Documentation ดำเนินคู่ขนานกับ fieldwork ตลอด — ไม่ใช่ทำตอนจบ. ทุก test, observation, finding ต้องบันทึกใน work papers ทันที
Phase 3: Reporting + Follow-up (ส่งมอบและติดตาม)
ขั้นนี้คือ “ปิด project” — สิ่งที่ board และ management ได้รับ
4 ขั้นตอน:
- Gather report requirements — มาตรฐาน + ข้อกำหนด external
- Draft report — IS audit leadership review ก่อน ตามด้วย auditee
- Issue report — รายงานสุดท้ายส่งให้ผู้รับและบันทึก
- Follow up — ติดตามว่า management ลงมือแก้ตาม recommendation มั้ย
→ ตอน 12 — Reporting & Communication จะเจาะเรื่องนี้
แล้ว ปิดวง ด้วย:
- ตรวจคุณภาพของ audit process เอง — Audit Committee oversight, IS audit QA, training
- → ตอน 13 — ปิด Domain 1 + QA + Recap
Audit Program: คู่มือก้าวต่อก้าวของ Engagement
มาเจาะรายละเอียดเรื่องแรกใน Section 1.5 ที่สำคัญในมุม project management ครับ
Audit Program คือ ชุด audit procedure + คำสั่งทีละขั้น ที่ใช้ทำ audit ตามที่ scope และ objective กำหนด
ลองนึกถึง project ก่อสร้าง — มี construction blueprint ที่บอกทุกขั้นตอน “วางฐานรากก่อน → ขึ้นเสา → เทพื้น → ก่อกำแพง…” — Audit Program คือ blueprint เดียวกันแต่สำหรับ audit project
4 จุดประสงค์ของ Audit Program
- Formal documentation ของ audit procedure ตามลำดับ
- Repeatable — ใช้ซ้ำกับ audit ที่คล้ายกันในอนาคต
- Documentation ของ testing type (manual / substantive)
- Comparison ผลที่ได้กับผลที่คาดหวัง
โครงสร้างของ Audit Program ที่ดี
ครอบคลุม:
- เข้าใจพื้นที่ที่จะตรวจ
- บันทึกความเข้าใจนั้น
- Risk assessment + general audit plan/schedule
- Detailed audit planning (steps + timeline)
- Preliminary review
- Evaluation ของพื้นที่
- Verifying control design ที่ตอบ control objectives
- Compliance testing
- Substantive testing
- Reporting communication
- Follow-up
- Samples, walk-throughs, documentation
ทักษะขั้นต่ำที่ต้องมีก่อนเขียน Audit Program
- เข้าใจ enterprise/industry risk types
- IT data governance
- ความสัมพันธ์ระหว่าง business risk กับ IT risk
- ความรู้เกี่ยวกับ business processes
- เข้าใจ IS control testing procedures (GAS, specialized software, flowcharting)
ทักษะเหล่านี้ไม่ได้มาจากการอ่านตำรา แต่มาจาก experience ในงาน audit + การ shadow senior auditor
Audit Work Papers: สะพานระหว่าง Objective กับ Report
Audit Work Papers คือเอกสารบันทึก audit programs, activities, tests, และ findings ทั้งหมด
หน้าที่หลักของ work papers: เป็นสะพานเชื่อมระหว่าง audit objective กับ final report ที่ต้อง trace ได้ ทั้งสองทิศทาง:
- จาก objective → report: คำตอบใน report มาจาก work papers ที่ตอบ objective
- จาก report → objective: ทุก finding ใน report trace กลับไปยัง objective ที่ทำให้เกิดการตรวจ
ลองนึกถึง สัญญาที่ตรวจสอบย้อนหลังได้ — ทุกบรรทัดของ work papers คือใบเสร็จที่บอกว่า “ทำอะไร เมื่อไหร่ โดยใคร พบอะไร”
Security Requirements ของ Work Papers
Work papers อาจมี information ที่ sensitive กว่า ระบบที่กำลังถูกตรวจ:
- รายชื่อ control weaknesses ที่ยังไม่แก้
- รายการ access accounts ของ system administrators
- System vulnerabilities ที่ยังไม่ patch
- Network diagrams ที่แสดงจุดอ่อน
ดังนั้น work papers ต้องได้รับการรักษาความปลอดภัย เทียบเท่ากับ production data ของ auditee — และมี retention/destruction process ตาม legal requirements ของ audit type นั้น
หลักการ Traceability
ทุก finding ใน final report ต้อง trace กลับ ไปได้ถึง:
- Work paper ที่บันทึกหลักฐาน
- Audit step ใน audit program ที่ทำให้พบ
- Audit objective ที่กำหนดให้ทดสอบ
- Risk ที่ระบุใน planning phase
ถ้า trace ไม่ได้ → finding นั้น “ลอย” → ใน audit committee review หรือใน legal challenge อาจถูกตัดทิ้ง
การรับมือ Fraud, Irregularities และ Illegal Acts
ส่วนสุดท้ายของ Section 1.5 ที่ต้องเข้าใจ — บทบาทของ IS auditor เมื่อสงสัยมีการทุจริต
ใครรับผิดชอบป้องกัน Fraud?
Management — ไม่ใช่ IS auditor เป็นผู้รับผิดชอบหลักในการตั้ง controls ที่ป้องกัน/ตรวจจับ fraud
ตรงนี้สำคัญมาก — IS auditor ไม่ใช่นักสืบ fraud หน้าที่หลักคือทำ audit ตาม scope ที่กำหนด
แต่ IS Auditor ก็ปิดตาไม่ได้
แม้ไม่ใช่หน้าที่หลัก IS auditor ต้อง ตื่นตัว (alert) ต่อ fraud indicators ตลอดเวลา fieldwork
ลองนึกถึง ทันตแพทย์ที่เห็นมะเร็งช่องปากระหว่างขูดหินปูน — ไม่ใช่หน้าที่หลัก แต่ถ้าเห็นแล้วเฉยไม่ได้ ต้องบอกผู้ป่วย
ถ้าเจอ Fraud Indicators ทำยังไง?
หลักการ ISACA ระบุชัด:
- สอบสวนต้องเป็นความลับ (discreet) — ไม่แจ้งใครก่อนยืนยัน
- ตามนโยบายและกฎหมาย — ไม่ลัดขั้นตอนแม้คิดว่าเร่งด่วน
- คำนึงถึง timing ของการสื่อสาร — บางครั้งการแจ้งเร็วเกินไปทำให้ผู้กระทำผิดทำลายหลักฐาน
- ถ้า major fraud + risk of detection สูง → consult audit management ทันที (ไม่ใช่จัดการเอง)
ใน Report ต้องเขียนอะไร?
ถ้าตรวจพบ fraud ที่ material:
- ต้องรายงานใน final report — ไม่มีข้อยกเว้น (ตาม Code of Ethics หลักการที่ 6)
- การปิดบัง = violate Code of Ethics
- แต่วิธีรายงานต้องระมัดระวัง — อาจต้องมี separate confidential annex
นี่คือเหตุผลที่ ตอน 02 (Independence) สำคัญมาก — ถ้า IS auditor ไม่อิสระจาก management ที่อาจเกี่ยวข้องกับ fraud ก็จะรายงานความจริงไม่ได้
ตำแหน่งของ Part B ใน Lifecycle
ก่อนปิดบทนี้ขอวางแผนที่ Part B ทั้งหมดให้เห็นในภาพเดียว — ทุกบทถัดไปอยู่ตรงไหนของ engagement lifecycle
ANNUAL PLAN (จาก Part A) ↓ENGAGEMENT เริ่มต้น ↓┌─────────────────────────────┐│ Phase 1: PLANNING │ ← ตอน 08 (บทนี้)│ - Engagement letter ││ - Audit objectives + scope ││ - Audit program │└─────────────────────────────┘ ↓┌─────────────────────────────┐│ Phase 2: FIELDWORK ││ - Test controls │ ← ตอน 09 Testing & Sampling│ - Collect evidence │ ← ตอน 10 Evidence Collection│ - Use analytics │ ← ตอน 11 Data Analytics│ - Document in work papers │ ← ตอน 08 (บทนี้)└─────────────────────────────┘ ↓┌─────────────────────────────┐│ Phase 3: REPORTING │ ← ตอน 12 Reporting│ - Communication of results ││ - Recommendations ││ - Follow-up │└─────────────────────────────┘ ↓┌─────────────────────────────┐│ CLOSE THE LOOP │ ← ตอน 13 QA + Domain 1 close│ - QA of audit process ││ - Audit committee review ││ - Training + improvement │└─────────────────────────────┘ ↓NEXT YEAR'S ANNUAL PLAN (วนใหม่)ทุกบทถัดไปจะอ้างอิงกลับมาที่ลำดับนี้ — และทุก concept จะมีที่อยู่ใน phase ใด phase หนึ่งเสมอ
ถ้า Phase ของ engagement ในหัวคุณชัด — บทถัดไปจะอ่านเป็น “เครื่องมือใน toolbox ของ phase นี้” ไม่ใช่ “ศัพท์ใหม่ที่ต้องท่อง”
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 1: Section 1.5 Audit Project Management
