ฉาก 1 — SME เปิดใหม่ ไม่มีใครคิดเรื่อง audit#

ลองนึกถึงร้านกาแฟเปิดใหม่ในซอย หรือบริษัท SaaS เริ่มต้น 3 คน หรือบริษัทรับเหมาก่อสร้างที่เถ้าแก่ลงเงินเอง

ถามจริง — มีใครนั่งคิดตั้งแต่วันแรกว่า “ต้องเก็บ audit log ของระบบ ERP ไว้ 7 ปี”? หรือ “ต้องแยกคนสร้าง user account ออกจากคนอนุมัติ”? หรือ “ต้องมี policy ควบคุมการเข้า WiFi บริษัท”?

ไม่มีหรอกครับ ใครคิดแบบนั้นตั้งแต่ Day 1 = ธุรกิจเดินไม่ทันเกิด โดนคุมกำเนิดก่อน

วันแรกเขาคิดแค่ว่า — ทำยังไงให้ขายได้ ทำยังไงให้คนรู้จัก ทำยังไงให้รอดเดือนนี้ก่อน เรื่อง control ทั้งหลายมาทีหลัง

ฉาก 2 — ปัญหาเริ่มเกิด (นี่คือจุดที่ Risk โผล่)#

แล้ววันหนึ่งก็เกิดเรื่องครับ

• พนักงานบัญชีลาออก เอา list ลูกค้าไปเปิดร้านเอง
• โดน hack — ข้อมูลลูกค้ารั่ว ลูกค้าเก่าโทรมาด่าทุกวัน
• พนักงาน procurement สร้าง vendor บัง ปลอม invoice จ่ายเงินให้ตัวเอง 2 ปี กว่าจะจับได้
• ระบบล่มกลางวันเสาร์อาทิตย์ ไม่มี backup ลูกค้าหายไปครึ่งหนึ่ง

เมื่อเรื่องเหล่านี้เกิด เจ้าของธุรกิจเริ่มเห็น “ความเป็นไปได้ที่จะเสียหาย” — นี่คือ Risk ในภาษาที่ ISACA ใช้

Risk ไม่ใช่เรื่องในตำราที่ใครเอามาขายให้บริษัท — มันคือสิ่งที่เจ้าของธุรกิจ เห็นแล้วเจ็บมาแล้ว

ฉาก 3 — เริ่มหาวิธีแก้ (นี่คือจุดที่ Control เกิด)#

พอเจ็บปุ๊บก็เริ่มคิดวิธีแก้ปัญหา

• “ต่อไปนี้ต้องปิดสิทธิ์เข้าระบบทันทีที่พนักงานยื่นใบลาออก”
• “ต้องตั้ง firewall + เปิด log ทุก server”
• “ต้องแยกคนสร้าง vendor ออกจากคนอนุมัติ payment”
• “ต้อง backup ข้อมูลสำคัญทุกคืน + เก็บไว้ที่อื่นด้วย”

วิธีแก้พวกนี้แหละครับคือ Control — กลไกที่ตั้งใจวางไว้เพื่อ ลดความเสี่ยง ที่เห็นมาแล้ว

สังเกตว่า Control ไม่ได้มาจาก “อ่านตำราแล้วทำตาม” — มันมาจาก เจ็บแล้วแก้ เป็นหลัก

ฉาก 4 — ธุรกิจโต Control เริ่มเป็นระบบ#

ตอนแรก control คือ “เถ้าแก่บอกห้ามทำ” — บอกปากเปล่า

ธุรกิจโตขึ้น มีพนักงาน 50 คน 100 คน → บอกปากเปล่าไม่พอ → เริ่มเขียนเป็น policy/procedure

โตอีก → เริ่มมี department หลายแผนก ที่ออก policy ของตัวเอง → IT ออกเรื่อง access control / HR ออกเรื่องลาออก / Finance ออกเรื่อง approval limit

โตอีก → เริ่มมี CIO/CISO มาจัดระบบให้

ตอนนี้ control ในบริษัทเริ่มเยอะ เริ่มซับซ้อน เริ่มต้องการคนมา govern

ฉาก 5 — แต่ละบริษัททำคนละแบบ → เกิด Framework#

ทุกบริษัทมาถึงจุดนี้พร้อมๆ กันในประวัติศาสตร์ — แต่ละบริษัทคิดเองทำเอง คนละมาตรฐาน

มีปัญหาตามมา:

• บริษัท A พูดว่า “เรามี control ครบ” แต่เทียบกับบริษัท B ที่พูดเหมือนกัน — ทำคนละเรื่องเลย
• ลูกค้าจะเลือก vendor ยังไง ในเมื่อทุกเจ้าก็บอกว่าตัวเองมี control
• เวลามีปัญหาฟ้องร้อง — ใช้มาตรฐานอะไรตัดสินว่าใครทำดีพอ

→ คนในวงการเลยรวมตัวกัน ออกมาตรฐานกลาง — กำเนิด Framework

• COBIT — สำหรับการ govern IT
• ISO 27001 — สำหรับ information security
• NIST CSF — สำหรับ cybersecurity
• ITIL — สำหรับ IT service management
• ITAF — สำหรับ IT audit (อันนี้เพิ่งคุยกันใน ตอน 01)

ใครทำตาม framework ครบ = พิสูจน์ได้ว่าทำตามมาตรฐานวงการ

ฉาก 6 — แล้วใครจะตรวจว่าทำตาม framework จริง?#

นี่คือจุดที่น่าสนใจที่สุดครับ และเป็นจุดที่ผมว่า CRM เล่าไม่ค่อยชัด

ตอนแรก — เถ้าแก่ตรวจเอง

บริษัทเล็กๆ เถ้าแก่ก็เป็นทุกอย่าง CEO ก็คือเถ้าแก่ CFO ก็คือเถ้าแก่ คนตรวจ control ก็เถ้าแก่ ใช้สามัญสำนึก ใช้ตาดูเอง พอแล้ว

โตขึ้นหน่อย — ครอบครัว/ผู้บริหารตรวจกัน

ลูกชายดู finance พี่สะใภ้ดู HR เพื่อนสนิทดู IT — ก็พอใช้ได้

โตอีก — เริ่มจ้าง professional manager

เถ้าแก่จ้าง CIO/CFO/CISO มาจริงๆ แล้ว — แต่นี่คือจุดที่เริ่มมีปัญหาตัวใหม่

ปัญหา conflict of interest ที่ค่อยๆ ปรากฏ

CIO ที่ดูแลระบบ IT ทั้งหมด ถ้าให้เขาตรวจตัวเองว่า “ระบบ IT ของบริษัทมี control พอมั้ย” — จะตอบยังไง? ตอบ “ไม่พอ” = บอกว่าตัวเองทำงานไม่ดี ตอบ “พอแล้ว” = อาจไม่จริง

นี่คือเหตุผลทางธุรกิจที่ทำให้เกิดแนวคิด SoD — Segregation of Duties ที่ “คนทำต้องไม่ใช่คนตรวจ”

ขั้นต่อไป — แยกบทบาทให้ชัด

ธุรกิจที่โตขึ้นเรื่อยๆ จะเริ่มจัดโครงสร้างใหม่:

• Management = ทำงาน + ออกแบบ control
• Internal Audit / IS Audit function = ตรวจว่า control ทำงานจริง
• Audit Committee = oversight ของทีม audit (อยู่ใน board)
• Board of Directors = รับผิดชอบ governance ทั้งบริษัท

โครงสร้างนี้ทำให้ คนตรวจไม่อยู่ใต้คนถูกตรวจ — ซึ่งคือ Independence เชิงโครงสร้าง ที่คุยกันไปใน ตอน 02

ฉาก 7 — Stakeholder เริ่มเรียกร้อง#

ระหว่างที่ภายในบริษัทค่อยๆ จัดโครงสร้าง stakeholder ภายนอกก็เริ่มเข้ามามีบทบาท:

• ผู้ถือหุ้น อยากรู้ว่าเงินที่ลงไปถูกใช้อย่างไร
• ลูกค้า อยากรู้ว่าข้อมูลที่ฝากไว้ปลอดภัยมั้ย
• regulator (ธนาคารแห่งประเทศไทย, ก.ล.ต., สคบ., สำนักงานคุ้มครองข้อมูลส่วนบุคคล ฯลฯ) บังคับให้ต้องมีระบบตรวจสอบที่น่าเชื่อถือ
• คู่ค้า อยากรู้ว่าธุรกิจที่ทำด้วยมีระบบ control พอมั้ย

ทุกฝ่ายต้องการ ความน่าเชื่อถือ ที่มาจาก คนที่ไม่ใช่ฝ่ายเดียวกัน มาตรวจให้

ฉาก 8 — Board approve Charter (handoff!)#

ถึงจุดนี้ board เห็นความจำเป็นแล้วว่าต้องมี IS audit function ที่:

• มีอำนาจเข้าถึงระบบ IT ทั้งหมด
• เป็นอิสระจาก management ที่ถูกตรวจ
• รายงานตรงต่อ board / audit committee
• ทำงานตามมาตรฐานวิชาชีพที่วงการยอมรับ

→ board ออกเอกสารชื่อ Audit Charter เพื่อให้อำนาจอย่างเป็นทางการกับทีม IS audit

Charter คือจุดที่มุมมอง business handoff ไปยังมุมมอง auditor — ก่อน Charter ทุกอย่างเป็นเรื่องของเจ้าของธุรกิจ หลัง Charter เป็นเรื่องของคนที่จะมาตรวจให้

Flow ของครึ่งแรก#

1
ปัญหาเกิด (Risk)
2
    ↓
3
หาวิธีแก้ (Control)
4
    ↓
5
Control เยอะขึ้น → Policy / Procedure
6
    ↓
7
แต่ละบริษัททำคนละแบบ → Framework (COBIT, ISO 27001, ITAF...)
8
    ↓
9
ใครจะตรวจว่าทำตาม Framework?
10
    ↓
11
เถ้าแก่ตรวจเอง → ครอบครัว → ผู้บริหาร → SoD → แยกบทบาท
12
    ↓
13
Stakeholder ภายนอกต้องการความน่าเชื่อถือ
14
    ↓
15
Board approve Audit Charter ← จุด handoff

ขั้น 1 — เปิด Charter อ่าน#

อ่าน Charter เพื่อรู้ว่า:

• เรามีอำนาจตรวจอะไรบ้าง
• ขอบเขต (scope) ครอบคลุมระบบไหน
• เรารายงานต่อใคร (โดยปกติคือ audit committee)
• เราทำได้แค่ assurance หรือทำ consulting ด้วยได้

ขั้น 2 — สร้าง Audit Universe#

จากขอบเขตที่ Charter กำหนด เราเริ่มทำ list ทุกพื้นที่ที่อยู่ในขอบเขต:

• ระบบ IT ทั้งหมด (ERP, CRM, HR system, financial system, …)
• กระบวนการที่ใช้ IT (ขายของออนไลน์, จ่ายเงินเดือน, …)
• vendor ที่ host ระบบให้เรา (cloud provider, SaaS vendor, …)
• หน่วยงานที่ใช้ระบบ IT มาก (IT department, finance, sales, …)

ทุกอย่างนี้รวมกันเรียกว่า Audit Universe — จักรวาลของสิ่งที่เราตรวจได้ตามอำนาจ

ลองนึกง่ายๆ ว่ามันคือ “list ของลูกค้าที่อาจจะเข้าหาเรา” สำหรับธุรกิจ — เราอาจไม่ได้เจอทุกคนทุกปี แต่ทุกคนอยู่ใน radar

ขั้น 3 — Risk Assessment ของ Universe#

Universe มีเป็นร้อยรายการ — ตรวจทุกอันทุกปีไม่มีทางทัน

→ ใช้ Risk Assessment เป็นเครื่องจัดอันดับ:

• ระบบไหน critical สุด? (ระบบเงินเดือน vs. ระบบจองห้องประชุม — ต่างกันมาก)
• ระบบไหนเปลี่ยนแปลงเยอะ? (just migrated to cloud = high risk)
• ระบบไหนมีประวัติ incident มาก่อน?
• ระบบไหนถูกกำกับโดยกฎหมายเฉพาะ? (ระบบที่เก็บ personal data = ต้อง comply PDPA)

ผลลัพธ์: ranked list ที่บอกว่า “ตรวจอันไหนก่อน-หลัง”

เดี๋ยว Section 1.3 จะมาเจาะลึกเรื่องเทคนิค risk assessment กับ planning hierarchy 4 ชั้นกัน — ขั้นนี้เห็นภาพรวมก่อนพอ

ขั้น 4 — Annual Audit Plan#

จาก ranked list → ทำ แผนประจำปี ว่า 12 เดือนข้างหน้าจะตรวจอะไรบ้าง อันไหน Q1, Q2, Q3, Q4

แผนนี้ต้องส่งให้ audit committee อนุมัติด้วย — ไม่ใช่ทีม audit ตัดสินใจเอง

ขั้น 5 — เลือกประเภท Audit ที่จะทำ#

แต่ละงานในแผนใช้ “เครื่องมือ” คนละแบบ:

• ตรวจ ERP ที่บริษัทเพิ่ง implement = อาจใช้ Integrated Audit (รวม financial + operational + IT)
• ตรวจ vendor cloud ที่ host ระบบให้เรา = ใช้ Third-party Audit หรือพึ่ง Service Audit Report (SOC)
• เจอเหตุสงสัยทุจริต = ทำ Forensic Audit
• อยากให้ business unit ตรวจตัวเองก่อน เราเป็น facilitator = Control Self-Assessment (CSA)
• ตรวจประจำปีปกติ = IS Audit มาตรฐาน

เดี๋ยว Section 1.2 จะมาเจาะลึก 11 ประเภท audit ที่ ISACA จัดไว้ + วิธีเลือกใช้ — ขั้นนี้เห็นภาพรวมก่อนพอ

ขั้น 6 — Engagement: ลงสนามจริง#

เลือกได้ว่าจะใช้ audit แบบไหนแล้ว ก็เข้าสู่ engagement — งานตรวจรอบนั้นๆ

ในแต่ละ engagement เราต้อง:

• ทำ Engagement Letter กับ auditee — ระบุ scope, timeline, deliverable
• ลง fieldwork — สัมภาษณ์, ดู document, ทดสอบระบบ
• สังเกต Control ที่ออกแบบไว้ทำงานจริงมั้ย
• เก็บ Evidence (เอกสาร, log, screenshot, การยืนยันจากบุคคลที่สาม)

ขั้น 7 — ดู Control ในระบบจริง#

ตรงนี้คือหัวใจของการตรวจ — ดูว่า control ที่บริษัทอ้างว่ามี ทำงานจริงตามที่บอกมั้ย

Control ที่เจอในการตรวจอาจเป็น:

• Preventive — ป้องกันก่อน (firewall, password policy)
• Detective — ตรวจจับเมื่อเกิด (SIEM, log monitoring)
• Corrective — แก้เมื่อเจอ (incident response procedure)
• Recovery — กู้คืน (backup + DR plan)

แต่ละประเภทมี timing คนละแบบ — ก่อนเหตุ / ระหว่างเหตุ / หลังเหตุ

เดี๋ยว Section 1.4 จะมาเจาะลึก control 5+ ประเภท + ความสัมพันธ์ risk-control + framework prescriptive vs risk-based — ขั้นนี้เห็นภาพรวมก่อนพอ

ขั้น 8 — ออก Report กลับ board#

จบ fieldwork → analysis → เขียน report:

• Finding — เจออะไรบ้าง
• Risk ที่ finding นี้สื่อถึง
• Recommendation — ควรแก้ยังไง
• Management Response — ฝ่ายที่ถูกตรวจตอบสนองยังไง

Report นี้ส่งให้ audit committee → board → ใช้เป็นข้อมูลตัดสินใจในการ govern บริษัท

Section 1.7-1.9 (Part B) จะมาเจาะลึกเรื่อง evidence collection, audit testing, sampling, reporting — ตอนนี้รู้แค่ว่ามันคือ deliverable สุดท้ายที่ส่งกลับไปก็พอ

ขั้น 9 — Follow-up#

ออก report ไม่ใช่จบงาน — หลังจากนั้นต้อง:

• ติดตามว่า management แก้ตาม recommendation มั้ย
• ตรวจซ้ำว่าแก้แล้วได้ผลจริง
• ปิดประเด็นเมื่อ control ใหม่ทำงานได้ตามคาดหวัง

→ พอจบ cycle หนึ่ง → ปีหน้ากลับไปขั้น 3 (risk assess Universe ใหม่) เริ่มใหม่อีกรอบ

Flow ของครึ่งหลัง#

1
Charter (จาก board)
2
    ↓
3
Audit Universe (พื้นที่ทั้งหมดในขอบเขต)
4
    ↓
5
Risk Assessment (จัดอันดับว่าอันไหนก่อน)  ← Section 1.3
6
    ↓
7
Annual Audit Plan
8
    ↓
9
เลือกประเภท Audit ที่เหมาะ  ← Section 1.2
10
    ↓
11
Engagement Letter + Fieldwork
12
    ↓
13
ดู Control ในระบบ  ← Section 1.4
14
    ↓
15
เก็บ Evidence + Test  ← Section 1.6, 1.7 (Part B)
16
    ↓
17
Report → Board / Audit Committee  ← Section 1.9 (Part B)
18
    ↓
19
Follow-up  ← Section 1.9 (Part B)
20
    ↓
21
ปีหน้าวนกลับไป Risk Assessment ใหม่