สารบัญ
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 จัดทีม ลงมือก่อ ตรวจงาน ส่งมอบ แล้วก็ตามแก้รายการที่ลูกค้าชี้ทีหลัง
audit engagement ก็เหมือนกันครับ ไม่ใช่แค่ “ลงไปตรวจ” แต่เป็น project ที่ต้องบริหารทุกมิติของ project management:
- Scope — จะตรวจอะไร ไม่ตรวจอะไร
- Time — เริ่มเมื่อไหร่ จบเมื่อไหร่ deliverable แต่ละชิ้นส่งวันไหน
- Resource — ใครในทีมทำอะไร ต้องใช้ทักษะอะไรบ้าง
- Quality — มาตรฐานวิชาชีพที่ต้องทำตาม
- Risk — risk ของตัว project เอง (ไม่ใช่ของ auditee) คือ engagement นี้มีอะไรเสี่ยงที่จะส่งไม่ทันบ้าง
ISACA กำหนด 4 เทคนิค project management สำหรับ audit project:
- Plan the engagement — ดู risk เฉพาะของงานนี้
- Build the audit plan — วาง task ตาม timeline และประเมิน resource ตามจริง
- Execute the plan — เดินตาม milestone ที่วางไว้
- Execute oversight — รายงาน actual เทียบกับ planned, คุม scope ให้อยู่ใน time + budget
ในมุม IS auditor มี 5 มิติที่ต้องดูทุกครั้งที่ประเมิน project:
- 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 ที่กำลังถูกตรวจ” (เช่น “ป้องกันการป้อนค่าเงินผิดในระบบ”)
ทักษะสำคัญของ IS auditor ในขั้นนี้คือ แปล broad audit objective ให้กลายเป็น IS-specific audit objective ที่ทดสอบได้
Phase 2: Fieldwork + Documentation (ลงสนาม + บันทึก)
ขั้นนี้คือ “ทำงานจริง” — ใช้เวลาส่วนใหญ่ของ engagement
4 ขั้นตอน:
- Acquire data — ขอ evidence ตาม list ที่วางไว้ เก็บแบบ traceable
- Test controls — ใช้ testing technique อย่าง 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 — รวบ standards + ข้อกำหนด external ที่เกี่ยวข้อง
- Draft report — ให้ IS audit leadership review ก่อน แล้วค่อยส่ง auditee
- Issue report — ปล่อย final 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
- ประเมินพื้นที่
- ตรวจ 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 ตามกลับไปหา objective ที่ทำให้เกิดการตรวจได้
ลองนึกถึง สัญญาที่ตรวจสอบย้อนหลังได้ ทุกบรรทัดของ work papers คือใบเสร็จที่บอกว่า “ทำอะไร เมื่อไหร่ โดยใคร พบอะไร”
Security Requirements ของ Work Papers
Work papers อาจมีข้อมูลที่ sensitive กว่า ระบบที่กำลังถูกตรวจด้วยซ้ำ:
- รายการ control weaknesses ที่ยังไม่ได้แก้
- รายการ access account ของ system administrator
- System vulnerabilities ที่ยังไม่แพตช์
- Network diagram ที่ชี้จุดอ่อน
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 เมื่อสงสัยว่ามีการทุจริต
3 คำที่ ISACA ใช้แยกกัน — และทำไมต้องแยก
ก่อนคุยเรื่องบทบาท ขอ flag คำ 3 คำที่ CRM + ISACA Standard 1207 ใช้ร่วมกันแต่คนละความหมาย — exam ออกถามแยกได้:
- Fraud — การกระทำที่ตั้งใจหลอกลวงเพื่อประโยชน์ส่วนตัว / ผลประโยชน์ทับซ้อน เช่น พนักงาน procurement สร้าง vendor บังเพื่อเบิกเงินเข้าตัวเอง
- Irregularities — กว้างกว่า fraud — ครอบคลุม “การกระทำที่ผิดปกติ” ที่อาจตั้งใจหรือไม่ตั้งใจก็ได้ เช่น misstatement ใน financial report, รายการที่ classify ผิด, transaction ที่ไม่ตามนโยบาย — Irregularity ที่ตั้งใจทำคือ Fraud, ที่ไม่ตั้งใจคือ error
- Illegal Acts — การฝ่าฝืนกฎหมาย ไม่ว่าจะตั้งใจหรือไม่ — เช่น ละเมิด PDPA, anti-money-laundering violation, tax evasion (ในไทยรวมถึงการละเมิด พ.ร.บ. คอมพิวเตอร์)
ทำไม ISACA ต้องแยก 3 คำ? เพราะ response ของ auditor ต่างกัน:
- เจอ Fraud → ระวัง confidentiality + เก็บ evidence ที่ admissible ในศาล
- เจอ Irregularity ที่ไม่ใช่ fraud → flag เพื่อ correction — ไม่จำเป็นต้องแจ้ง regulator
- เจอ Illegal Act → อาจมี legal reporting obligation บังคับ (เช่น แจ้ง regulator + ตำรวจ ภายใน timeframe ที่กฎหมายกำหนด)
ตอนสอบเจอ scenario ที่ใช้คำว่า “irregularity” → อย่าเหมาเอาว่า fraud เพราะอาจไม่ใช่. และคำว่า “illegal act” = trigger สำหรับ reporting obligation พิเศษ — ที่ระเบียบบริษัทเอาไม่อยู่
ใครรับผิดชอบป้องกัน 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)
- ปิดบัง = ผิด Code of Ethics
- แต่วิธีรายงานต้องระวัง อาจต้องแยกเป็น 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
