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