สารบัญ
ผมเพิ่งเข้าใจว่าทำไม audit report หลายฉบับถึงถูก board เปิดอ่านครั้งเดียวแล้ววางไว้บนชั้น
ตอนผมอ่าน Section 1.9 รอบแรก ผมคาดว่าจะเจอ template ของรายงาน — หัวข้ออะไรไว้ตรงไหน เขียนยังไงให้ดูเป็นทางการ ปรากฏว่าสิ่งที่ ISACA สอนคนละเรื่องเลยครับ มันสอนว่า report ที่ “ทำงานได้” คือ report ที่เปลี่ยนพฤติกรรมขององค์กรหลังอ่าน ไม่ใช่ report ที่สวยที่สุด ความต่างนี้สำคัญมาก เพราะมันบังคับให้เขียนโดยคิดถึงคนอ่านเป็นที่ตั้ง ไม่ใช่คิดถึงตัวเองเป็นที่ตั้ง
ที่ทำให้ผมต้องอ่านซ้ำหลายรอบคือคำว่า discuss findings กับ AUDITEE ก่อน ไม่ใช่ audit client ตอนแรกผมเข้าใจสลับครับ คิดว่ารายงานต้องส่งให้ผู้ว่าจ้างก่อน พอเข้าใจตรรกะว่า “ต้องให้คนที่อยู่กับ control นั้นจริงได้มีโอกาส clarify context ก่อน” บทบาทของ auditor ในใจผมเปลี่ยน — จาก “ผู้ตัดสินที่ส่งคำพิพากษาให้นาย” กลายเป็น “ผู้ตรวจที่คุยกับเจ้าของบ้านก่อน แล้วค่อยรายงานนาย” มันเคารพคนทำงานหน้างานมากกว่า
อีกประโยคที่กระทบใจคือ “audit ที่ไม่มี follow-up = audit ที่ไม่มีประสิทธิผล” — ทำให้เห็นว่า output ของ audit ไม่ใช่ report แต่คือ controls ที่ improve หลัง report บันทึกตอนนี้เลยจะปูตั้งแต่ 6 objectives ไปจนถึง follow-up เพื่อให้เห็นว่าทำไมทุกชิ้นต้องอยู่ด้วยกัน
Recap: Engagement ใกล้ปิดแล้ว
ใน ตอน 09 ถึง ตอน 11 เราคุยเรื่อง Phase 2 Fieldwork ทดสอบ controls, เก็บ evidence, ใช้ analytics
ตอนนี้ทุก test เสร็จ evidence เก็บครบ work papers ก็ documented แล้ว → ขั้นต่อไปคือ Phase 3: Reporting + Follow-up
แต่ “ออก report” ไม่ใช่แค่ “เขียนรายงานแล้วส่ง” มันมี framework ที่ ISACA กำหนดไว้ชัดเจน ทั้ง:
- ทำไม ออก report (objectives)
- ใคร ได้รับ report (audience)
- อะไร อยู่ใน report (structure + content)
- ยังไง สื่อสาร (timing + channel)
- อะไรต่อ หลัง report (follow-up)
ถ้า audit ทำเสร็จแล้วไม่มีใครรู้ผล → ROI ของ audit ทั้ง engagement = ศูนย์
6 Objectives ของ Audit Report
ก่อนเขียน report ต้องรู้ก่อนว่า report ทำงาน 6 อย่างพร้อมกัน:
- Identify observations สำหรับ auditees (ไม่ใช่ audit client ถ้าเป็นคนละกลุ่ม)
- Formal closure ของ audit engagement — ปิดงานอย่างเป็นทางการ
- ให้ IT / senior management เห็น area ที่ต้อง corrective actions + recommendations
- เป็น reference สำหรับใครก็ตามที่จะ review auditee ในเรื่อง audit topic
- กำหนด timeline สำหรับ next review
- สร้าง audit credibility — ขึ้นกับ report ที่ well-developed + well-written
Report ต้อง ตั้งอยู่บน:
- Requirements จาก auditee management + other users
- Compliance กับ IS audit / assurance standards
- Audit organization policies
ทุก objective ต้องตรงกัน — ถ้า report เน้นแค่ identify problems แต่ไม่ recommend → ผิด objective 3 ถ้า report ดีแต่ส่งให้ผิดคน → ผิด objective 1 กับ 4
Auditee vs. Audit Client: ความต่างที่ Exam ออก
จุดแรกที่สำคัญและ exam ชอบหลอก — discuss findings กับใครก่อน?
Auditee = หน่วยงาน / บุคคลที่ถูก audit (เช่น IT department ที่กำลังถูกตรวจ) Audit Client = ผู้ว่าจ้าง audit (เช่น board หรือ senior management)
หลายกรณี auditee กับ audit client เป็นคนละกลุ่มกัน
กฎของ ISACA: discuss findings กับ AUDITEE ก่อน ไม่ใช่ audit client
ทำไม? เพราะ:
- Auditee คือคนที่อยู่กับ control นั้นจริง
- Auditee อาจมี context ที่ทำให้ finding เปลี่ยนการตีความ
- คุยแล้วถึงจะ confirm finding ก่อนส่ง audit committee / board
Audit Committee: ทางออกพิเศษ
Audit Committee = กลุ่มบุคคลที่ ไม่อยู่ในกำลังคนของ organization เป็นอิสระจาก management
หน้าที่ — ให้ IS auditor มีช่องทาง independent ในการรายงาน sensitive findings ที่ management อาจอยากปกปิด
ลองนึกถึง scenario:
- IS auditor พบว่า CFO ไปเปลี่ยนระบบ accounting หลังปิดงบ
- ถ้ารายงานต่อ CEO ตรงๆ CEO อาจเลือกปกปิด
- แต่ถ้ารายงานต่อ audit committee → independent oversight → ไม่มีใครปิดได้
audit committee = “safety valve” ของ corporate governance
บริษัทที่ไม่มี audit committee หรือ audit committee ไม่ได้ประชุม regularly → IS audit function ไม่มี backdoor ปลอดภัยให้รายงาน sensitive findings อันนี้คือ red flag ของ governance
Audit Report Structure
รูปแบบ exact varies by organization — แต่ basic components เป็น standard
Components หลัก
-
Introduction
- Audit objectives
- Limitations / scope
- Period of coverage
- Overview of procedures
- Statement ของ IS audit standards ที่ followed
-
Findings
- นำเสนอเป็น sections
- มัก grouped ตาม materiality + intended recipient
-
Overall Conclusion + Opinion
- Adequacy ของ controls
- Actual / potential risk จาก deficiencies ที่พบ
-
Reservations / Qualifications (ถ้ามี)
- กรณีพิเศษที่ทำให้ opinion ไม่สมบูรณ์ 100%
-
Detailed Findings + Recommendations
- IS auditor ระบุว่า controls adequate หรือ inadequate
- Evidence ที่เก็บ → provides level of assurance
-
Specific Findings ตาม Materiality + Intended Recipient
- Report สำหรับ audit committee ≠ report สำหรับ local management
- Detail level ปรับตาม audience
กฎสำคัญ: Balance ใน Report
Report ต้องสมดุล ไม่ใช่แค่ list ของปัญหา
ต้องมีทั้ง:
- Negative findings — control weaknesses, deviations
- Positive circumstances — controls ที่ทำงานดีอยู่แล้ว
ทำไม Balance ถึงสำคัญ?
ถ้า report แสดงแต่ปัญหา:
- Auditee ตั้งการ์ด → resist recommendations
- Management รู้สึกถูกโจมตี → ไม่ implement
- Audit กลายเป็น “ผู้คุกคาม” แทนที่จะเป็น “พันธมิตร”
ถ้ายอมรับ effective controls ด้วย:
- Auditee รู้สึกถูกเคารพ → ยอมรับ recommendations มากขึ้น
- สร้าง relationship ระยะยาว
- Audit value ขยายจาก compliance → improvement partnership
IS auditor ใช้ independence ในการเขียน report ไม่ใช่เพื่อหลบปัญหา แต่เพื่อนำเสนอภาพรวมที่ถูกต้อง
Action Recommendations
หลังเจอ findings ต้องมี recommendations ที่ practical
หลักการ Recommendations
- ส่งตรงถึงคนที่ implement ได้ — ไม่ใช่ทุกคน แต่เป็นคนที่มีอำนาจตัดสินใจ
- ไม่ใช่ทุก recommendation ต้อง implement ทันที — ต้องคำนึงถึง business priority + risk decision ของ management
- คุย recommendations + planned implementation date ก่อนปล่อย report
- ขอ commitment จาก auditee management เรื่องวันที่จะ implement
Implementation Reality
IS auditor ต้องเข้าใจว่า recommendation ที่ดีไม่ใช่ recommendation ที่ “ครบที่สุด” แต่เป็น recommendation ที่ “implement ได้จริงในบริบทธุรกิจ”
ตัวอย่าง:
- Recommendation ทั่วไป: “Implement multi-factor authentication ทุก user”
- Recommendation ที่ดี: “Phase 1 — implement MFA สำหรับ privileged accounts ใน Q3, Phase 2 — ขยายไปยัง all users ใน Q4 ถ้า Phase 1 สำเร็จ”
Phase 2 มี implementation path ที่ realistic + measurable
Report Issuance Rules
ออก report ใน timely manner ไม่ปล่อยค้างหลัง fieldwork เสร็จเป็นเวลานาน
Significant findings อาจ communicate ก่อน final report ได้ แต่ prior communication ต้องไม่ delay report issuance
นี่เป็นจุดที่ exam ชอบหลอก:
- ❌ “ต้องรอ auditee response ก่อนปล่อย final report”
- ✅ “Prior communication ของ significant findings ต้องไม่ delay final report”
Auditee มีสิทธิ์ response แต่ response นั้นไม่ block การ issue report
Documentation: หลักฐานสนับสนุนทุก Conclusion
Audit Documentation = written record ที่สนับสนุน representation ใน audit report
3 หน้าที่หลัก:
- แสดง ว่า engagement ทำตาม applicable IS audit / assurance standards
- รองรับ basis ของ conclusion ที่ auditor ให้
- ทำให้ audit replicable / reviewable ใครก็ตามที่จะ review งาน auditor ภายหลังต้อง trace ตามได้
Required Documentation Elements
ต้องมี:
- Planning + preparation ของ scope + objectives
- Description / walk-through ของ audit areas
- Audit program
- Audit step ที่ทำ + evidence ที่เก็บ
- การใช้ auditor อื่น / expert (ถ้ามี)
- Audit findings, conclusions, recommendations
- Audit documentation cross-reference ไปยัง working paper identification + date
- Copy of report ที่ issue ออกไป
Optional but recommended: Evidence ของ audit supervisory review
Materiality ใน Documentation
จะ document อะไรขึ้นกับ materiality:
- Site-level material — Terminated user’s access ไม่ถูก remove แต่ยังไม่เคยถูก abuse → material สำหรับ site management แต่อาจไม่ material ที่ HQ
- Top-level material — Segregation of duty failure → material แม้ที่ top management level
IS auditor ต้องตัดสินว่า finding “ใหญ่” แค่ไหนก่อนเลือก documentation depth
Documentation Rules
- Clear, complete, easily retrievable, sufficiently comprehensible
- เป็น property of the auditor เปิดให้เฉพาะ authorized personnel
- ต้องขอ prior approval ก่อนให้ external parties (ยกเว้นกรณีกฎหมายบังคับ)
Follow-Up: ที่ทำให้ Audit “สร้างคุณค่า”
นี่คือส่วนที่ผู้บริหารหลายคนข้าม และเป็นเหตุที่ ROI ของ audit หายไป
กฎของ ISACA:
“IS auditor is NOT effective if audits are performed/reported with no follow-up”
แปล — audit ที่ไม่มี follow-up = audit ที่ไม่มีประสิทธิผล
หน้าที่ของ Follow-up
- Monitor ว่า management ลงมือ corrective actions มั้ย
- Confirm ว่า action ถูก implement จริง
- สื่อสารผล follow-up ไปยัง management level ที่เหมาะสม
- Timing ขึ้นกับ criticality ของ findings
Degree of Follow-Up Effort
ตั้งแต่:
- Simple inquiry ถามถึง status เฉยๆ (lightweight)
- ไปจนถึง…
- ทำ audit step เพื่อ confirm ว่า corrective action ถูก implement (heavyweight)
Internal vs. External Follow-up
- Internal IS auditors → SHOULD ทำ follow-up
- External audit firm IS auditors → โดย practice แล้ว อาจไม่ ทำ follow-up แต่ทำได้ถ้าตกลงไว้
องค์กรที่ใช้ external audit อย่างเดียวก็เลยมักไม่มี systematic follow-up → เป็นปัญหา
Why Follow-Up = Value Creation
ROI ของ audit ไม่ใช่ output ของ report แต่คือ controls ที่ improve หลัง audit
Audit ที่ออก report แล้วหายไป = audit ที่แทบไม่มีประโยชน์ Audit ที่ follow up จนเห็น corrective action ถูก implement = audit ที่สร้างมูลค่า
Audit committee ที่ดีจะถาม: “เดือนที่แล้วเราพบ 5 findings — implement ไปแล้วกี่ findings ที่ค้างคือเรื่องอะไร ทำไม?”
Types of Reports
Report type ขึ้นกับ:
- ประเภทของ audit engagement
- Reporting requirements
Standard
Most IS audits → simple IS audit report / status statement
กรณีที่ต้องมีมากกว่า 1 Report
- General audience report — สำหรับ board / senior management ที่ต้องการ business-level summary
- Confidential security report — สำหรับ technical team ที่ต้องการรายละเอียด technical (vulnerability, attack vector) ที่ไม่ควรเปิดเผยทั่วไป
ตัวอย่าง — penetration test ของระบบ
- Report 1 (general): “ระบบมี security weakness ที่ต้องแก้ตาม priority list”
- Report 2 (confidential): รายละเอียดของ exploit + path ที่ใช้ทดสอบ → ส่งเฉพาะ security team
Trap Patterns ที่ Exam ออก
| Trap | ความเข้าใจผิด | ความเข้าใจที่ถูก |
|---|---|---|
| Discuss findings กับ “audit client” | สับสนว่ารายงานครั้งแรกให้ใคร | Discuss กับ AUDITEE ก่อน (ไม่ใช่ audit client ถ้าต่างกัน) |
| Audit committee = management | คิดว่า audit committee เป็นส่วนของ management | Audit committee = independent of management — สำหรับ sensitive route |
| Report = แค่ negative findings | คิดว่า report = list ปัญหา | ต้อง balance — both weaknesses + effective controls |
| ทุก recommendation ต้อง implement | คิดว่า auditee ต้องทำตามทุกข้อ | Management prioritizes; IS auditor obtain commitment + timeline แต่ไม่ force |
| Follow-up = optional | คิดว่า nice-to-have | Internal: SHOULD do follow-up; ไม่มี follow-up = ineffective |
| Prior communication delays final report | คิดว่าต้องรอ auditee response | Prior communication ต้อง ไม่ delay report issuance |
| Documentation = แค่ report เอง | คิดว่า document แค่ output | Documentation = ทุก step (planning, fieldwork, evidence, conclusions) |
Cross-Reference
สิ่งที่ผมเก็บได้จากบทนี้
ในมุมผม Section 1.9 เป็นบทที่ “เปลี่ยนวิธีคิดเรื่องการเขียน” ของผมมากที่สุดในทั้ง Domain 1 ครับ มันสอนเรื่อง balance — report ที่ดีไม่ใช่ report ที่ระบุปัญหาเยอะที่สุด แต่เป็น report ที่นำเสนอภาพรวมที่ถูกต้องรวมถึงสิ่งที่ทำงานดีอยู่แล้ว ฟังดูเหมือนเรื่องนิสัย แต่จริงๆ มันเป็น เทคนิคทำให้คำแนะนำได้รับการ implement จริง ครับ ถ้าคน defensive ตั้งแต่ย่อหน้าแรก ไม่มี recommendation ไหนเข้าหู
ที่ผมคิดว่าจะติดอยู่ในใจเป็นพิเศษคือบทบาทของ audit committee — “safety valve ของ corporate governance” สำหรับ findings ที่ management อาจอยากปกปิด ตรงนี้ทำให้ผมเข้าใจว่าทำไมบริษัทที่ governance ดีต้องมี audit committee ที่ประชุม regularly ไม่ใช่แค่ on paper ถ้า audit ไม่มี independent route ในการรายงาน sensitive findings ก็คือไม่มี audit จริง
สิ่งที่ผมจดสำหรับวันสอบสั้นๆ — discuss กับ AUDITEE ก่อน, audit committee = independent จาก management, report ต้อง balance ทั้ง positive + negative, follow-up ต้องเกิดถึงจะ effective, prior communication ไม่ delay report issuance ห้าอันนี้ผูกกัน trap ใน table ส่วนใหญ่ก็ตามกฎเหล่านี้
บทถัดไปจะปิด Domain 1 ด้วยเรื่องที่ดู “meta” หน่อย — audit function ตรวจคุณภาพตัวเองยังไง + recap ทั้ง Domain 1 ก่อนเข้า Domain 2
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 1: Section 1.9 Reporting and Communication
