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

เมื่อพูดถึง “กฎหมายที่เกี่ยวกับ IS audit” มีสองชุดที่แยกกันชัดเจนครับ และสองชุดนี้ต้องการความสนใจคนละแบบ

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

กฎหมายและ regulations บางอย่างกำหนดว่า IS audit ต้องทำยังไง ใครมีสิทธิ์ทำ การรายงานต้องเป็นรูปแบบใด บางประเทศกำหนด mandatory audit สำหรับอุตสาหกรรมเฉพาะ เช่น กฎหมายในบางประเทศที่บังคับให้สถาบันการเงินต้องมี independent IS audit อย่างน้อยปีละครั้ง หรือกำหนดว่า auditor ต้องมี credentials ที่ได้รับการรับรองแล้ว

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

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

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

ลองดูตัวอย่างที่เป็นรูปธรรมสำหรับบริบทไทย:

• PDPA (พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล) — กำหนดว่าต้องจัดการ personal data อย่างไร ต้องมี consent กรณีใดบ้าง ต้องเก็บรักษาข้อมูลอย่างไร IS audit ต้องตรวจว่า controls สำหรับ data management ทำตาม PDPA จริง ไม่ใช่แค่ว่า policy เขียนไว้ว่าทำ

• ประกาศของ Bank of Thailand สำหรับสถาบันการเงิน — กำหนด IT risk management requirements ที่ธนาคารต้องปฏิบัติตาม รวมถึง data governance, incident response, system availability standards IS audit ของธนาคารจึงต้องครอบคลุมพื้นที่เหล่านี้โดยปริยาย ไม่ว่า risk score จะเป็นอะไร

• ข้อกำหนด SEC สำหรับบริษัทจดทะเบียน — กำหนด internal control requirements ที่เกี่ยวกับ financial reporting ซึ่งรวมถึง IT controls ที่รองรับ financial systems IS audit จึงต้องตรวจว่า IT general controls และ application controls สำหรับระบบ financial ทำตาม SEC requirements

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

IS Auditor ตรวจ Compliance อย่างไร: 6 Steps ที่ต้องทำ#

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

Step 1: ระบุ requirements ที่เกี่ยวข้องกับองค์กรนี้

เริ่มต้นด้วยการสำรวจว่ากฎหมายและ regulations อะไรบ้างที่ใช้กับองค์กรนี้ในแง่ IS — ครอบคลุมทั้ง IS systems, IT practices, วิธีจัดเก็บและใช้งาน data, กิจกรรมของ IT services และ service providers ภายนอก

เหมือนกับหมอที่ต้องรู้ก่อนว่าคนไข้คนนี้มีประวัติยาที่แพ้อะไรบ้าง ก่อนจะเริ่มสั่งยา — IS auditor ต้องรู้ compliance landscape ก่อนเริ่มวางแผนตรวจครับ

Step 2: บันทึก applicable laws และ regulations อย่างเป็นระบบ

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

Step 3: ตรวจสอบว่า management พิจารณา requirements เหล่านั้นแล้วหรือยัง

นี่คือ step ที่สำคัญมาก — ไม่ใช่แค่ว่ากฎหมายมีอยู่ แต่องค์กรได้นำ 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 หรือ third-party data processor — contracts เหล่านั้นต้องสะท้อน legal requirements ด้วย เช่น vendor contract ต้องมีข้อกำหนดเกี่ยวกับ data protection ที่สอดคล้องกับ PDPA ในฐานะ data processor

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

สิ่งที่ CISA ไม่ได้ทดสอบ — และทดสอบจริง#

ผมอยากเน้นจุดนี้เป็นพิเศษครับ เพราะผู้อ่านหลายคนมักกังวลว่าต้องท่องกฎหมายแต่ละฉบับก่อนสอบ CISA

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

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

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

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

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

หรืออีก scenario:

“IS auditor พบว่าองค์กรมีระบบ cloud storage ที่ใช้เก็บ personal data ของลูกค้า สิ่งแรกที่ควรทำในส่วน compliance คืออะไร?”

คำตอบ: ระบุและบันทึกกฎหมาย/regulations ที่ใช้กับ cloud storage + personal data ในประเทศนั้น แล้วค่อยประเมินว่า management จัดการกับ requirements เหล่านั้นอย่างไร — ไม่ใช่ลงไปตรวจ technical configuration ทันที

Compliance Testing กับ Substantive Testing: สองเครื่องมือที่ Risk Assessment บอกว่าใช้อันไหน#

นอกจาก 6 steps สำหรับ compliance assessment แล้ว ยังมีอีกมิติหนึ่งที่ D1.05 เชื่อมต่อกับงาน audit จริง นั่นคือการเลือกประเภทของ testing ครับ

IS auditor มีเครื่องมือทดสอบอยู่สองชุดหลักที่ใช้ใน fieldwork:

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

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

คำถามคือ: IS auditor จะเลือกใช้อันไหนมากกว่ากัน?

นี่คือจุดที่ risk assessment เข้ามา: ผลการประเมิน control environment ขององค์กรนั้นๆ เป็นตัวบอก

ถ้า IS auditor ทำ risk assessment แล้วพบว่า controls แข็งแกร่ง ได้รับการออกแบบและทำงานอย่างดี — audit approach ที่สมเหตุสมผลคือทำ compliance testing มากขึ้น เพื่อยืนยันว่า controls ทำงานจริง และลด substantive testing ลงได้บ้าง เพราะมีเหตุผลเชื่อว่า data น่าจะถูกต้อง

แต่ถ้าพบว่า controls อ่อนแอ มีช่องโหว่ หรือออกแบบไม่ดี — ต้องทำ substantive testing มากขึ้นเพื่อยืนยันข้อมูลโดยตรง เพราะ controls ที่อ่อนแอบอกว่าข้อมูลอาจมีข้อผิดพลาดหรือความผิดปกติ

สรุปหลักการ: Strong controls → ทำ compliance testing มาก, substantive testing น้อยลง ได้ / Weak controls → ต้องทำ substantive testing มากขึ้น เพื่อชดเชยการขาด control assurance

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

Compliance เป็นส่วนหนึ่งของ Risk-Based Planning ไม่ได้แทนที่กัน#

มีความเข้าใจผิดที่ต้องแก้ตรงนี้ครับ: บางคนมองว่า 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 ระดับกลาง แต่เพราะ Bank of Thailand กำหนด requirements ไว้ชัดเจน — audit ของระบบนี้จึงเป็น mandatory สำหรับแผนประจำปีอยู่ดี

สิ่งที่ IS auditor ต้องทำในสถานการณ์แบบนี้คือสร้างสมดุลระหว่าง “mandatory compliance coverage” กับ “highest risk areas” ซึ่งเป็นการตัดสินใจที่ต้องพิจารณาทั้ง regulatory obligations และ risk environment พร้อมกัน

Trap Pattern ที่ CISA ชอบออกข้อสอบ#

มุมผู้บริหาร: Compliance คือ Risk จริง ไม่ใช่แค่ “หน้าที่ Legal”#

หลายองค์กรมองว่า compliance ด้าน IS/IT เป็นเรื่องของ legal department หรือ compliance officer เท่านั้น — IS audit แค่ “check the box” ตามที่ legal บอก

แต่นั่นคือความเข้าใจผิดที่มีราคา

ความต่างระหว่าง “compliance บนกระดาษ” กับ “compliance ที่ทำงานจริง” คือสิ่งที่ IS audit ตรวจ ไม่ใช่แค่ว่ามี policy อยู่มั้ย

PDPA บอกว่าต้องมี data protection officer — แต่ทำงานจริงๆ มั้ย? ระบบที่ประมวลผล personal data ถูกบันทึกและรักษาความปลอดภัยตาม standards มั้ย? มี controls ที่บังคับใช้ data retention requirements จริงหรือเปล่า? Vendor ที่จัดการ customer data รู้ภาระหน้าที่ของตัวเองมั้ย?

IS auditor เป็นคนที่รู้ว่า ในทาง technical แล้ว องค์กรทำตาม requirements ได้จริงๆ มั้ย Legal สามารถยืนยันว่า policy เขียนถูก แต่ IS auditor ต่างหากที่ยืนยันว่าระบบและ controls ทำตาม policy นั้นจริงหรือเปล่า

มีอีกมิติที่สำคัญสำหรับผู้บริหาร: กฎหมายเปลี่ยน → audit plan ต้องเปลี่ยน

PDPA ประกาศใช้ → audit plan ต้องเพิ่ม privacy compliance review เข้าไป BoT ออก circular ใหม่เรื่อง cloud adoption → audit plan ต้องปรับ scope สำหรับ cloud systems ถ้า audit function ไม่มีกระบวนการติดตาม regulatory changes และอัปเดตแผนรับกฎใหม่ — บริษัทเสี่ยงโดนค่าปรับโดยที่ audit ไม่เคยส่งสัญญาณเตือน

ความเสี่ยงที่แท้จริงคือองค์กรที่ “ผ่าน compliance” เพราะเอกสารดี แต่ระบบจริงๆ ยังมีช่องโหว่ที่ทำให้ personal data โดน breach ได้ — นั่นคือความล้มเหลวที่แพงกว่าค่าปรับมาก เพราะ regulatory action + ความเสียหายต่อชื่อเสียง + การสูญเสียความเชื่อมั่นของลูกค้า มาพร้อมกันครับ

ดังนั้น audit committee ที่ดีต้องถาม IS auditor ว่า: “regulatory changes ในปีนี้ส่งผลให้ audit plan ของเราต้องปรับอะไรบ้าง?” ถ้าคำตอบคือ “ไม่มีอะไร” ตลอดทุกปี — นั่นอาจเป็นสัญญาณว่า audit function ไม่ได้ติดตาม regulatory landscape อย่างที่ควรจะเป็น

จากการวางแผนสู่การเลือกประเภท Audit#

ตอนนี้เราเข้าใจว่า IS audit planning มีกรอบชัดเจน — ตั้งแต่ Audit Universe ไปจนถึง legal compliance requirements รวมถึงว่า risk assessment ช่วยขับเคลื่อนการเลือกระหว่าง compliance testing กับ substantive testing

แต่ยังมีคำถามที่ยังไม่ตอบ: ใน audit engagement ที่วางแผนไว้แต่ละครั้ง — IS auditor ทำ audit แบบไหน?

เพราะ IS audit ไม่ได้มีรูปแบบเดียว มีหลายประเภทที่ออกแบบมาสำหรับวัตถุประสงค์ที่ต่างกัน บางครั้งเหมาะสำหรับตรวจ controls โดยตรง บางครั้งตรวจว่า financial statement ถูกต้องมั้ย บางครั้งต้องการหลักฐานสำหรับศาล

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