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

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

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

ไม่มีหรอกครับ 555+ ใครคิดแบบนั้นตั้งแต่ 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#

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 กำหนด เราก็เริ่มไล่รายการทุกพื้นที่ที่อยู่ในขอบเขต:

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

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

ลองนึกง่ายๆ ว่ามันคือ “รายชื่อลูกค้าที่อาจจะเข้าหาเรา” สำหรับธุรกิจ เราอาจไม่ได้เจอทุกคนทุกปี แต่ทุกคนอยู่ใน 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 บริษัท

ก่อนถึง final report ตัวจริง CRM ระบุไว้ด้วยว่า auditor “อาจ” สื่อสาร finding กลับให้ management แบบ informal ก่อนได้ — เรียกว่า letter of management เป็นการแจ้งเรื่องที่เจอระหว่างทาง (interim findings) เพื่อให้ management เริ่มแก้ได้ทันโดยไม่ต้องรอวันที่ report ฉบับสมบูรณ์ออก แต่ letter of management ไม่ได้แทนที่ formal report นะครับ มันคือช่องสื่อสารเสริมระหว่าง engagement

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 ของส่วนที่ 2#

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 ใหม่