ใน ตอน 06 เราเพิ่งเห็นว่า IS auditor วางแผนตรวจอย่างไร — สร้าง Audit Universe, ใช้ risk assessment จัดอันดับ, ผ่าน 4 ชั้นของ planning hierarchy

แต่ planning ยังไม่ครบ เพราะมีอีก input หนึ่งที่ บังคับ ให้ต้อง audit บางพื้นที่ ไม่ว่า risk score จะบอกอะไร — กฎหมาย / regulations

ตอนนี้คือบทสุดท้ายของ Part A — เราจะปิดเรื่อง compliance + laws แล้วสรุปภาพรวม Part A ทั้ง 8 ตอน + เตรียมตัวเข้า Part B

ทำไมกฎหมายเป็น Input ที่ Risk-Based Planning ไม่พอ#

ลองนึกถึงตอนที่ พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล (PDPA) มีผลบังคับใช้จริงในประเทศไทย

องค์กรหลายแห่งที่เคยมองว่า “data privacy ไม่ใช่ risk ลำดับต้น” กลายเป็นต้องรีบเพิ่ม compliance review เข้าแผน audit ทันที — ไม่ใช่เพราะ risk assessment ภายในบอก แต่เพราะ กฎหมายบังคับ

นี่คือประเด็นแรกที่ ISACA อยากให้เข้าใจ: กฎหมาย + regulations ภายนอกไม่ได้ “เพิ่มขึ้นมาในแผน” แต่เป็น mandatory input ที่ต้องเข้ามาตั้งแต่ Day 1 ของ audit planning ไม่ว่า risk score ภายในจะบอกอะไร

สองมิติของ Legal Requirements ใน IS Audit#

เมื่อพูดถึง “กฎหมายที่เกี่ยวกับ IS audit” มี 2 ชุด ที่แยกกันชัดเจน

มิติที่ 1: กฎหมายที่บังคับใช้กับ audit conduct เอง#

กฎหมายและ regulations บางอย่างกำหนดว่า IS audit ต้องทำยังไง ใครมีสิทธิ์ทำ การรายงานต้องเป็นรูปแบบใด

ตัวอย่าง: บางประเทศบังคับให้สถาบันการเงินต้องมี independent IS audit อย่างน้อยปีละครั้ง หรือกำหนดว่า auditor ต้องมี credentials ที่ได้รับการรับรอง

ในส่วนนี้ IS auditor ต้องรู้ว่าตัวเองอยู่ภายใต้ข้อจำกัดอะไรบ้างก่อนเริ่มงาน

มิติที่ 2: กฎหมายที่กำหนด requirements ให้กับ auditee#

กลุ่มที่กว้างกว่ามาก — กฎหมายที่บังคับให้องค์กรต้องทำอะไรบางอย่างกับ data, systems, การรายงาน ซึ่ง IS audit ต้องตรวจว่าองค์กรปฏิบัติตามหรือเปล่า

ตัวอย่างในบริบทไทย:

PDPA (พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล) — กำหนดว่าต้องจัดการ personal data อย่างไร ต้องมี consent กรณีใด ต้องเก็บอย่างไร IS audit ต้องตรวจว่า controls ทำตาม PDPA จริง ไม่ใช่แค่ว่า policy เขียนไว้ว่าทำ
ประกาศของธนาคารแห่งประเทศไทย — กำหนด IT risk management requirements ที่ธนาคารต้องปฏิบัติ รวมถึง data governance, incident response, system availability standards IS audit ของธนาคารจึงต้องครอบคลุมพื้นที่เหล่านี้โดยปริยาย
ข้อกำหนด ก.ล.ต. สำหรับบริษัทจดทะเบียน — กำหนด internal control requirements ที่เกี่ยวกับ financial reporting รวมถึง IT controls ที่รองรับ financial systems

ทั้งสามตัวอย่างมี pattern เดียวกัน: regulator ภายนอกบอกว่า “พื้นที่นี้ต้องถูกตรวจ” — IS auditor ต้องตอบสนองด้วยการรวมพื้นที่นั้นเข้าใน audit scope ไม่ใช่ตัดสินใจจาก risk score ภายในอย่างเดียว

6 Steps ของ Compliance Assessment#

ISACA กำหนด approach ที่ชัดเจนว่า IS auditor ต้องทำอะไรเพื่อตรวจว่าองค์กรจัดการ compliance requirements อย่างถูกต้อง

Step 1: ระบุ requirements ที่เกี่ยวข้อง สำรวจกฎหมายและ regulations ที่ใช้กับองค์กรในแง่ IS — ครอบคลุม IS systems, IT practices, การจัดเก็บ data, IT services และ third-party providers

Step 2: บันทึก applicable laws & regulations อย่างเป็นระบบ ต้องมีบันทึกชัดเจนว่ากฎอะไรบ้างที่ใช้บังคับ ไม่ใช่แค่รู้ในหัว เอกสารนี้จะเป็นข้อมูลอ้างอิงสำหรับ audit team และการตรวจทานโดย audit committee

Step 3: ตรวจสอบว่า management พิจารณา requirements แล้วหรือยัง ไม่ใช่แค่ว่ากฎหมายมีอยู่ — แต่องค์กรนำ requirements ไปสะท้อนใน policies, standards, procedures, features ของระบบหรือเปล่า

ตัวอย่าง: PDPA กำหนดว่าต้องมี data retention policy ถ้า IS audit พบว่า management รู้เรื่อง PDPA แต่ยัง “กำลังจะทำ policy” → นั่นคือ gap ที่ต้องรายงาน

Step 4: ตรวจทาน IS department reports เกี่ยวกับ compliance status ดูว่า IS department มี self-assessment หรือ monitoring reports เกี่ยวกับ compliance อยู่มั้ย รายงานเหล่านั้นบอกว่าองค์กรอยู่ที่ไหน + outstanding issues อะไรค้างอยู่

Step 5: ตรวจสอบว่า established procedures สอดคล้องกับ requirements ไม่ใช่แค่ว่ามี procedure อยู่ — แต่ procedure นั้นสอดคล้องกับสิ่งที่กฎหมายกำหนดมั้ย บางองค์กรมี procedure ที่เขียนมาตั้งนานก่อน PDPA จะมีผลบังคับใช้ แล้วยัง “อัปเดตแล้ว” แต่จริงๆ ยังขาดส่วนสำคัญ

Step 6: ตรวจสอบ external service provider contracts ถ้าองค์กรใช้ cloud vendor, outsourced IT provider — contracts เหล่านั้นต้องสะท้อน legal requirements ด้วย เช่น vendor contract ต้องมีข้อกำหนดเกี่ยวกับ data protection ที่สอดคล้องกับ PDPA

step นี้สำคัญเพราะหลายองค์กรลืมตรวจ vendor contracts เวลากฎหมายใหม่ออกมา แล้วมาพบทีหลังว่า contract เดิมไม่ได้ครอบคลุม

CISA ทดสอบอะไร — และไม่ทดสอบอะไร#

จุดที่ผู้สอบกังวลกันมากครับ

CISA จะไม่ถาม: กฎหมายฉบับเฉพาะใดๆ ไม่ว่าจะเป็น PDPA มาตราที่เท่าไหร่ SOX section ใด HIPAA requirement ข้อไหน — ไม่ต้องจำเลย

CISA จะถาม: IS auditor ควรทำอะไร “เพื่อตรวจสอบว่าองค์กรปฏิบัติตาม applicable laws” — ซึ่งคือ process และ approach ไม่ใช่เนื้อหาของกฎหมาย

ตัวอย่าง scenario ที่ CISA ชอบถาม:

“IS auditor กำลังวางแผน IS audit สำหรับ financial institution ขั้นตอนไหนที่ควรทำก่อนเพื่อจัดการกับ compliance requirements?”

คำตอบที่ถูก: ระบุ applicable requirements → บันทึก → ประเมินว่า management พิจารณา requirements ในการวางแผนแล้วหรือยัง — ไม่ใช่เรื่องว่าธนาคารแห่งประเทศไทยออกประกาศอะไรบ้าง

Compliance Testing vs Substantive Testing#

นอกจาก 6 steps ของ compliance assessment ยังมีอีกมิติที่เชื่อมต่อกับงาน fieldwork — การเลือกประเภทของ testing

IS auditor มีเครื่องมือทดสอบ 2 ชุดหลัก:

Compliance testing (test of controls) — ทดสอบว่า controls ที่มี “ทำงานตามที่ออกแบบไว้” มั้ย เหมือนตรวจว่าประตูล็อคอยู่จริงไหม ไม่ใช่ตรวจของในห้อง

Substantive testing — ตรวจสอบข้อมูลจริง ดูว่า transactions, records, amounts ถูกต้องและครบถ้วน เหมือนนับของในห้องเอง

คำถาม: ใช้อันไหนมากกว่ากัน?

คำตอบ: ขึ้นอยู่กับ risk assessment ของ controls

Strong controls → ทำ compliance testing มากขึ้น, substantive testing น้อยลง เพราะ controls ทำงานดี ข้อมูลน่าจะถูก
Weak controls → เพิ่ม substantive testing เพื่อยืนยันข้อมูลโดยตรง เพราะ controls ที่อ่อนแอบอกว่าข้อมูลอาจมีข้อผิดพลาด

CISA มักทดสอบเรื่องนี้: “ถ้า IS auditor พบว่า controls อ่อนแอ audit approach ควรเป็นอย่างไร?” → คำตอบ: เพิ่ม substantive testing

Compliance ≠ แทนที่ Risk-Based Approach#

ความเข้าใจผิดที่ต้องแก้: บางคนมองว่า compliance-driven audit กับ risk-based audit เป็นสองแนวทางที่ขัดกัน

ความจริง: ทั้งสองทำงาน ร่วมกัน

Compliance requirements เป็น input ชนิดหนึ่งใน risk assessment — เมื่อ IS auditor ทำ risk-based planning แล้วพบว่าพื้นที่หนึ่งมี regulatory requirements สูง → risk score ของพื้นที่นั้นก็สูงตาม เพราะผลกระทบที่อาจเกิดจาก non-compliance (ค่าปรับ, ความเสียหายต่อชื่อเสียง, regulatory action) คือ risk จริงๆ

ในทางปฏิบัติ องค์กรใน regulated industry จะมี compliance-heavy areas ที่ทำให้ audit scope บางพื้นที่กลายเป็น mandatory — แม้ risk score เชิงปฏิบัติการจะกลางหรือต่ำ

ตัวอย่าง: ธนาคารที่มีระบบ internet banking — ระบบนี้อาจมี operational risk ระดับกลาง แต่เพราะธนาคารแห่งประเทศไทยกำหนด requirements ชัดเจน → audit ของระบบนี้เป็น mandatory สำหรับแผนประจำปีอยู่ดี

IS auditor ต้องสร้างสมดุลระหว่าง “mandatory compliance coverage” กับ “highest risk areas”

สรุป Part A — Recap ทั้ง 8 ตอน#

ตอนนี้เราจบ Part A ของ Domain 1 แล้วครับ ขอย้อนภาพรวมให้เห็นทั้งหมด

ตอน	เรื่อง	คำถามที่ตอบ
0	CISA คืออะไร — เปิดเรื่อง	CISA คืออะไร ทำไมน่าเรียน
01	Rule Book — Standards / Guidelines / Tools / Code of Ethics / ITAF	กฎอะไรกำกับ IS auditor
02	Internal Audit Function + Audit Charter	ใครให้อำนาจ auditor มาตรวจ
03	IS Audit ตั้งแต่เริ่ม…จนจบ (Storyboard)	ภาพใหญ่ของวงจร audit ทั้งหมด
04	11 ประเภท Audit + CSA + Integrated	เลือก audit แบบไหน เพราะอะไร
05	ภาษา Risk + Control (ปูพื้นความรู้)	Risk Trinity, Materiality, 3 Methods, 5 Classifications
06	Risk-Based Planning + Audit Universe + 4 Layers	วางแผนตรวจอย่างไร
07	Compliance + Laws (ปิด Part A)	กฎหมายเป็น mandatory input ของแผน

3 บทเรียนสำคัญที่ Part A ฝังไว้ในหัว#

อ่าน Part A จบแล้ว ถ้าจำได้แค่ 3 อย่าง ขอให้จำ 3 เรื่องนี้:

1. Risk เป็นรากของทุกอย่าง ตั้งแต่ Charter (เพื่อให้คนกลางมาดู risk), Audit Universe (ขอบเขตที่ risk-based plan ทำงาน), ประเภท audit (เลือกตาม risk ของพื้นที่), Control (ออกแบบเพื่อจัดการ risk), จนถึง audit testing approach (ขึ้นกับ control risk) — ทุกการตัดสินใจของ auditor มี risk เป็นแกน

2. Independence คือ structural ไม่ใช่ attitude ตั้งแต่ Charter ที่ board อนุมัติ (ไม่ใช่ CIO), reporting line ที่ตรงต่อ audit committee, จนถึง CSA ที่เปลี่ยน auditor เป็น facilitator — โครงสร้างคือสิ่งที่ enforce ความเป็นกลางในระยะยาว ความตั้งใจอย่างเดียวไม่พอ

3. Management ทำ Risk Assessment — Auditor ตรวจคุณภาพ เส้นแบ่งความรับผิดชอบที่ ISACA เน้นมาก management = คนระบุ risk + ออกแบบ control / IS auditor = คนประเมินอย่างอิสระว่า risk assessment + controls นั้นเหมาะสมหรือเปล่า — อย่าสับสน

เตรียมตัวเข้า Part B: Execution#

Part A ทั้งหมดที่อ่านมา = “การเตรียมตัวก่อนลงสนาม”

รู้กฎ → มีอำนาจ (Section 1.1)
ปูพื้น → เลือก audit + ภาษา risk/control (Section 1.2)
วางแผน → audit universe + risk-based plan + compliance (Section 1.3, 1.4)

Part B คือ “ลงสนามจริง” — เนื้อหาจะเปลี่ยนจาก “เตรียมตัว” เป็น “ทำงาน”:

Section	เรื่อง	คำถามที่ตอบ
1.5	Audit Project Management	จัดการ engagement ครั้งหนึ่งยังไงให้ส่งมอบทันเวลา
1.6	Audit Testing & Sampling	ทดสอบ controls ยังไง เลือก sample เท่าไหร่
1.7	Audit Evidence Collection	เก็บหลักฐานยังไงให้ใช้ได้
1.8	Audit Data Analytics	ใช้ CAATs / continuous auditing / AI ช่วยตรวจ
1.9	Reporting and Communication	ออก report ยังไง สื่อสารกับ board ยังไง
1.10	Quality Assurance	ตรวจคุณภาพของ audit process ของตัวเอง

ทุกขั้นใน Part B จะอ้างอิงกลับมาที่ Part A เสมอ — ทุก test, ทุก sample, ทุก finding ล้วนต้อง trace กลับไปยัง risk + control + plan ที่เราวางไว้

ถ้า Part A ของคุณแน่น Part B จะอ่านง่ายมาก เพราะมันคือการเอาภาษาที่เรียนมาแล้วไปใช้กับสถานการณ์จริง

อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 1: Section 1.3 Risk-Based Audit Planning + Part A wrap-up