CISA Series ตอนที่ 12 : D1 - Reporting & Communication: ปิด Engagement ด้วย Report ที่ทำงาน

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 เห็น areas ที่ต้อง corrective actions + recommendations
Reference สำหรับใครก็ตามที่ review auditee ในเรื่อง audit topic
Set timeline สำหรับ next review
Promote audit credibility — depend on report ที่ well-developed + well-written

Report ต้อง ground ใน:

Requirements จาก auditee management + other users
Compliance กับ IS audit/assurance standards
Audit organization policies

ทุก objective ต้องตรงกัน — ถ้า report เน้นแค่ identify problems แต่ไม่ recommend → fail objective 3 ถ้า report ดี แต่ส่งให้ผิดคน → fail 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 of problems

ต้องมีทั้ง:

Negative findings — control weaknesses, deviations
Positive circumstances — controls ที่ทำงานดีอยู่แล้ว

ทำไม Balance สำคัญ?

ถ้า report แสดงแต่ปัญหา:

Auditee defensive → resist recommendations
Management feel attacked → ไม่ implement
Audit ที่ดูเป็น “ผู้คุกคาม” แทนที่จะเป็น “พันธมิตร”

ถ้า acknowledge effective controls:

Auditee feel respected → ยอมรับ recommendations มากขึ้น
Build relationship ระยะยาว
Audit value ขยายจาก compliance → improvement partnership

IS auditor ใช้ independence ในการเขียน report — ไม่ใช่หลีกเลี่ยงปัญหา แต่นำเสนอภาพรวมที่ accurate

Action Recommendations#

หลังจาก findings — ต้องมี recommendations ที่ practical

หลักการ Recommendations#

Direct ไปยังคนที่ implement ได้ — ไม่ใช่ทุกคน, แต่คนที่มีอำนาจตัดสินใจ
Not all recommendations implement ทันที — business priorities + risk decisions ของ management ต้องคำนึงถึง
Discuss recommendations + planned implementation dates ก่อนปล่อย report
Obtain commitment จาก auditee management on implementation date

Implementation Reality#

IS auditor ต้องเข้าใจ — recommendation ที่ดีไม่ใช่ recommendation ที่ “ครบที่สุด” แต่เป็น recommendation ที่ “implement ได้จริงในบริบทธุรกิจ”

ตัวอย่าง:

Recommendation ทั่วไป: “Implement multi-factor authentication ทุก user”
Recommendation ที่ดี: “Phase 1 — implement MFA สำหรับ privileged accounts ใน Q3, Phase 2 — extend ไป all users ใน Q4 ถ้า Phase 1 successful”

Phase 2 มี implementation path ที่ realistic + measurable

Report Issuance Rules#

Issue ใน 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 ของ auditee ไม่ block การ issue report

Documentation: หลักฐานสนับสนุนทุก Conclusion#

Audit Documentation = written record ที่สนับสนุน representations ใน audit report

3 หน้าที่หลัก:

Demonstrate ว่า engagement ทำตาม applicable IS audit/assurance standards
Support basis ของ auditor’s conclusions
Ensure audit เป็น replicable / reviewable — ใครก็ตามที่ review work ของ auditor ภายหลัง ต้อง trace ตามได้

Required Documentation Elements#

ต้องมี:

Planning + preparation ของ scope + objectives
Description / walk-throughs ของ audit areas
Audit program
Audit steps performed + evidence gathered
Use of other auditors / experts (ถ้ามี)
Audit findings, conclusions, recommendations
Audit documentation cross-reference ไปยัง working paper identification + date
Copy of report issued

Optional but recommended: Evidence of audit supervisory review

Materiality ใน Documentation#

อะไรที่ document depends on materiality:

Site-level material: Terminated user’s access ไม่ถูก remove แต่ไม่เคย abused → material สำหรับ site management แต่อาจไม่ใช่ 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 — accessible เฉพาะ authorized personnel
Prior approval required ก่อนให้ 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 ว่า actions implement จริง
Communicate ผล follow-up ไปยัง appropriate management levels
Timing depends on criticality ของ findings

Degree of Follow-Up Effort#

ตั้งแต่:

Simple inquiry เกี่ยวกับ status (lightweight)
ไปจนถึง…
Performing audit steps เพื่อ confirm corrective actions implemented (heavyweight)

Internal vs. External Follow-up#

Internal IS auditors: SHOULD do follow-up
External audit firm IS auditors: may NOT do follow-up โดย practice — แต่ทำได้ถ้า agreed

ดังนั้นองค์กรที่ใช้ external audit อย่างเดียวมักไม่มี systematic follow-up → ปัญหา

Why Follow-Up = Value Creation#

ROI ของ audit ≠ output ของ report — แต่คือ controls ที่ improve หลัง audit

Audit ที่ออก report แล้วหายไป = audit ที่แทบไม่มีประโยชน์ Audit ที่ follow up จนเห็น corrective actions implement = audit ที่สร้างมูลค่า

Audit committee ที่ดีจะถาม: “เดือนที่แล้วเราพบ 5 findings — implement ไปแล้วกี่ findings? ที่ค้างคือเรื่องอะไร? ทำไม?”

Types of Reports#

Report type driven by:

ประเภท audit engagement
Reporting requirements

Standard#

Most IS audits → simple IS audit report / status statement

Cases ที่ต้องการมากกว่า 1 Report#

General audience report — สำหรับ board / senior management ที่ต้องการ business-level summary
Confidential security report — สำหรับ technical team ที่ต้องการ technical details (vulnerabilities, attack vectors) ที่ไม่ควร disclose ทั่วไป

ตัวอย่าง: penetration test ของระบบ

Report 1 (general): “ระบบมี security weaknesses ที่ต้องแก้ตาม priority list”
Report 2 (confidential): รายละเอียดของ exploits + specific paths ที่ใช้ทดสอบ → ส่งเฉพาะ 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#

Reporting Phase → ขยายจาก Phase 3 ที่ outline ใน ตอน 08
Findings → Evidence → ทุก finding trace กลับ evidence จาก ตอน 10
Documentation → expand จาก work papers concept ใน ตอน 08
Audit Committee Independence → กลับไปดู ตอน 02 Charter + Independence

ในบทถัดไป — ปิด Domain 1 ด้วยเรื่องที่ดูจะ “meta” — audit function ตรวจคุณภาพตัวเองยังไง และ recap ทั้ง Domain 1 ก่อนเข้า Domain 2

อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 1: Section 1.9 Reporting and Communication