ทำไมกฎหมายเป็น 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 ชุด ที่แยกกันชัดเจน

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 แล้วครับ ขอย้อนภาพรวมให้เห็นทั้งหมด