CISA D1.04 — 4-Layer Planning Hierarchy: ทำไมถึงตรวจตรงนี้ก่อน

ลองนึกภาพว่าคุณเป็น IS auditor และเพิ่งได้รับมอบหมายให้ดูแล IS audit function ขององค์กรใหม่

บริษัทมีระบบ IT 40 ระบบ ทีมของคุณมี 5 คน และคุณมีเวลา 1 ปี

คำถามแรกที่ต้องตอบคือ: ตรวจระบบไหนก่อน?

ถ้าตอบว่า “ตรวจตามที่ management ขอ” — นั่นไม่ใช่คำตอบที่ดีครับ ถ้าตอบว่า “ตรวจตามลำดับหมายเลข” — นั่นก็ไม่ใช่ ถ้าตอบว่า “ตรวจสิ่งที่ auditor คิดว่าน่าสนใจ” — นั่นยิ่งไม่ใช่

คำตอบที่ถูกคือ: ตรวจตาม risk — และนั่นต้องอาศัย planning ที่มีโครงสร้างชัดเจน

4 ชั้นของ IS Audit Planning#

การวางแผน IS audit ไม่ใช่แผนเดียว แต่เป็นกระบวนการที่มี 4 ชั้นซ้อนกัน แต่ละชั้นตอบคำถามคนละอย่าง

ชั้นที่ 1: Audit Universe — “มีอะไรในโลกที่อาจต้องตรวจ?”#

Audit Universe คือรายการที่ครอบคลุม processes ทั้งหมดในองค์กรที่ผูกพันต่อการถูก audit

ไม่ใช่แค่ “ระบบ IT” — แต่รวมถึง business processes ทั้งหมดที่ใช้ IT สนับสนุน ถ้าบริษัทมีกระบวนการสั่งซื้อ, กระบวนการ payroll, กระบวนการจัดการข้อมูลลูกค้า — ทั้งหมดนี้อยู่ใน Audit Universe

ทำไมต้องมี Audit Universe? เพราะถ้าไม่รู้ว่ามีอะไรทั้งหมด ก็ไม่มีทางรู้ว่า “ตรวจครบ” หรือยัง

ชั้นที่ 2: Annual Plan — “ปีนี้จะตรวจอะไรบ้าง?”#

จาก Audit Universe ทั้งหมด — IS auditor ทำ risk assessment เพื่อจัดลำดับความสำคัญ

Risk assessment ใช้ risk factors ที่พิจารณาว่าถ้า process นั้นมีปัญหา จะส่งผลเสียต่อองค์กรแค่ไหน:

High — ถ้าเกิดปัญหา กว่าจะฟื้นตัวต้องใช้เวลาเกิน 6 เดือน
Medium — ฟื้นตัวใช้เวลา 3–6 เดือน
Low — ฟื้นตัวได้ภายใน 3 เดือน

Annual Plan คือรายการ processes ที่ถูกจัดว่า High risk — นั่นคือสิ่งที่ต้องตรวจในปีนี้เป็นอย่างน้อย

ความจริงที่ซ่อนอยู่: ในชีวิตจริง ทรัพยากรของ audit team มักไม่พอสำหรับการตรวจ High risk processes ทั้งหมด เมื่อเกิด resource gap ต้องบันทึกว่า gap นั้นมีอยู่และ residual risk ถูกยอมรับโดย management ระดับที่เหมาะสม — ไม่ใช่แค่ข้ามไปโดยไม่บอกใคร

Annual Plan ต้องผ่านใคร? ต้องถูกทบทวนโดย senior audit management และอนุมัติโดย audit committee (หรือ board of directors ถ้าไม่มี audit committee) และต้องสื่อสารให้ management ระดับที่เกี่ยวข้องรับรู้

Annual Plan ไม่ใช่เอกสาร “ทำแล้วจบ” — ถ้า risk environment เปลี่ยนอย่างมีนัยสำคัญ (เช่น บริษัทเพิ่งย้ายไป cloud, หรือมีการเปลี่ยนแปลงด้านกฎหมายสำคัญ) ต้องอัพเดทแผนด้วย

ชั้นที่ 3: Individual Audit Assignment — “งาน audit ครั้งนี้วางแผนยังไง?”#

เมื่อ annual plan กำหนดแล้วว่าจะตรวจอะไร — แต่ละงาน audit ยังต้องมีการวางแผนเฉพาะงานของตัวเอง

นี่คือกระบวนการ 10 ขั้นที่ ISACA กำหนดสำหรับการวางแผนแต่ละ IS audit engagement:

เข้าใจ mission, objectives, purpose, processes ขององค์กร รวมถึง availability, integrity, security, privacy ของข้อมูล
เข้าใจ governance structure ที่เกี่ยวกับ audit objectives
เข้าใจการเปลี่ยนแปลงใน business/IT environment โดยเฉพาะ processes และเทคโนโลยีที่เพิ่งเปิดตัว
ระบุ policies, standards, guidelines, procedures ที่บังคับใช้
ทำ risk analysis เพื่อออกแบบ audit plan
กำหนด audit scope และ objectives ให้ชัดเจน
พัฒนา audit approach หรือ audit strategy
จัดสรรทรัพยากรบุคคล ให้กับ audit
จัดการ engagement logistics (การเข้าถึง, ตารางเวลา, จุดติดต่อ)
ระบุวิธีการสำหรับ continuous audit ถ้าจะใช้ CAATs

การวางแผนแต่ละงาน audit ยังต้องพิจารณา: ผลการ risk assessment รอบล่าสุด, การเปลี่ยนแปลงของเทคโนโลยี, ประเด็นด้าน privacy ใหม่ๆ, regulatory requirements, ตารางเวลาการ implement ระบบ

ชั้นที่ 4: 5-Phase Execution — “ทำอย่างไร?”#

นี่คือชั้นที่ลงมือทำจริง แบ่งเป็น 5 phases หลัก (จะลงลึกใน D1.12) แต่ขอเล่าภาพรวมไว้ก่อน:

Planning — กำหนด subject, objectives, scope, risk assessment
Fieldwork — เก็บข้อมูล ทดสอบ controls ตรวจสอบ evidence
Documentation — บันทึกทุกอย่างใน work papers
Reporting — ร่าง, ทบทวน, ออก audit report
Follow-up — ติดตาม corrective actions

แต่ละ phase มีกิจกรรมและสิ่งที่ต้องส่งมอบเฉพาะของมันที่ต้องทำให้ครบ

ทำไม Risk-Based Approach ถึงสำคัญนัก?#

ตลอด 4 ชั้นนี้ เส้นเดียวที่ร้อยทุกอย่างเข้าด้วยกันคือ risk

ถ้า annual plan ไม่ risk-based — audit resources จะถูกใช้กับ processes ที่ไม่จำเป็น ขณะที่บริเวณที่มีความเสี่ยงสูงถูกปล่อยไป

ถ้า individual assignment ไม่มี risk analysis — audit scope อาจกว้างเกินไป (เสียเวลา) หรือแคบเกินไป (พลาดบริเวณที่สำคัญที่สุด)

Risk-based approach ต้องอาศัยความเข้าใจ 4 มิติ:

องค์กรมี mission, objectives, purpose อะไร
Policies และ procedures ถูกเลือกและนำไปใช้อย่างไร
อุตสาหกรรมและสภาพแวดล้อมขององค์กรเป็นยังไง
ผลการดำเนินงานถูกวัดและทบทวนอย่างไร

นอกจากนั้น IS auditor ยังต้องเข้าใจ:

Strategy management ขององค์กร
ผลิตภัณฑ์และบริการของธุรกิจ
Corporate governance process
ประเภท, รูปแบบและการไหลของ transactions ในระบบ IT

ทั้งหมดนี้เพื่อให้ risk assessment ที่ขับเคลื่อน audit plan มีความแม่นยำครับ ไม่ใช่ risk ที่ auditor “เดาว่าน่าจะสำคัญ”

มุมผู้บริหาร: ทำไม Audit Planning ถึงต้องใช้เวลา?#

หลายองค์กรที่ผมเคยเจอมักรู้สึกว่า IS audit ใช้เวลา “เตรียมตัว” นานเกินไป

แต่ถ้าเข้าใจ 4-layer planning hierarchy แล้ว จะเห็นว่า:

ถ้า IS auditor ข้ามขั้นตอน planning ไป — Audit Universe อาจไม่ครบ, Annual Plan อาจตรวจผิดบริเวณ, Individual assignment อาจกำหนด scope ผิด → ผลลัพธ์คือ audit report ที่ไม่จัดการกับความเสี่ยงจริงๆ

ถ้า planning ทำได้ดี — ทรัพยากรถูกใช้ตรงจุด, ทุก finding ที่ออกมามีบริบทว่าทำไมถึง material, management รู้สึกว่า audit เพิ่มคุณค่าจริง ไม่ใช่แค่ compliance exercise

IS audit ที่ดีต้องอาศัยเวลา planning พอๆ กับ fieldwork ครับ นั่นไม่ใช่ข้อเสีย แต่เป็นสัญญาณว่า audit function ทำงานอย่างมืออาชีพ

Risk Assessment Techniques: วิธีให้ Score กับ Risk#

ตรงนี้เป็นความลึกทางเทคนิคที่ D1.04 ต้องพูดถึง เพราะ risk-based planning ที่ดีต้องอาศัย risk assessment technique ที่หนักแน่น — ไม่ใช่แค่บอกว่า “คิดว่า high risk”

ISACA กำหนด 2 แนวทางหลักสำหรับ risk assessment ใน IS audit planning:

Approach 1: Scoring System

นี่คือแนวทางเชิงปริมาณที่กำหนดค่าตัวเลขให้กับ risk factors ต่างๆ เพื่อคำนวณ overall risk score

Risk factors ที่ใช้ประเมินอาจรวมถึง:

ความซับซ้อนทางเทคนิคของระบบหรือ process นั้น
ระดับของ existing control procedures ที่มีอยู่แล้ว
ระดับของ financial loss หรือผลกระทบถ้าเกิดปัญหา

ตัวแปรเหล่านี้อาจถูกถ่วงน้ำหนักต่างกัน (เช่น financial impact สำคัญกว่าความซับซ้อนทางเทคนิค 2 เท่า) หรือไม่ถ่วงน้ำหนักก็ได้ ขึ้นอยู่กับ risk appetite ขององค์กร ผล risk scores จากทุก process ถูกนำมาเปรียบเทียบกันเพื่อจัดลำดับความสำคัญว่า audit ไหนควรเกิดก่อน

ข้อดีของ scoring system คืออธิบายได้ครับ — ถ้าถูกถามว่า “ทำไมไม่ตรวจระบบ X ปีนี้?” คำตอบที่มีตัวเลขรองรับน่าเชื่อถือกว่า “เพราะ auditor คิดว่า risk ไม่สูง”

Approach 2: Subjective Assessment

นี่คือแนวทางเชิงคุณภาพที่ใช้ความรู้เกี่ยวกับธุรกิจ, วิจารณญาณและประสบการณ์แทนตัวเลข

แหล่งข้อมูลที่ป้อนเข้า subjective assessment ได้แก่:

ความรู้เกี่ยวกับธุรกิจที่ audit team มีต่อองค์กร
คำสั่งจาก executive management ว่า management กังวลอะไรเป็นพิเศษ
มุมมองทางประวัติศาสตร์ — อะไรที่เคยเป็นปัญหาในอดีต
เป้าหมายธุรกิจปัจจุบันว่าองค์กรกำลังให้ความสำคัญกับอะไร
ปัจจัยแวดล้อมที่เปลี่ยนไป เช่น การเปลี่ยนแปลงด้านกฎหมาย, การเปลี่ยนของตลาด

ทั้งสองแนวทางสามารถใช้ร่วมกันได้ และในทางปฏิบัติมักทำแบบนั้น — ใช้ scoring system เป็นฐาน แล้วปรับด้วย subjective judgment จาก management input และบริบททางธุรกิจ

สิ่งที่ CISA ชอบถามเกี่ยวกับเรื่องนี้: “ใครเป็นเจ้าของ risk assessment?” คำตอบ: management เป็นคนทำ risk assessment — IS auditor ทำหน้าที่ประเมินคุณภาพและความครบถ้วนของ risk assessment นั้น ไม่ใช่ทำแทน

Short-Term vs. Long-Term Planning#

สิ่งหนึ่งที่ ISACA เน้นและมักถูกมองข้ามคือ planning ต้องมีทั้งระยะสั้นและระยะยาว

Short-term planning พิจารณา audit issues ที่จะจัดการกับในปีนี้ — มาจาก risk assessment ปัจจุบัน, findings จาก audits ก่อนหน้า, การเปลี่ยนแปลงด้านกฎหมายที่เพิ่งเกิด

Long-term planning พิจารณา audit issues ที่เกิดจาก IT strategy ระยะยาวขององค์กร — เช่น ถ้าบริษัทวางแผนย้ายไป cloud ใน 3 ปี, audit function ต้องเตรียมขีดความสามารถและ audit methodology สำหรับ cloud environment ล่วงหน้า

ทั้งสองต้องถูกทบทวนอย่างน้อยปีละครั้ง และอัพเดทถ้า risk environment เปลี่ยน

จาก Planning สู่ Execution#

ตอนนี้เรามีภาพรวมของ 4 ชั้นแล้ว ในบทถัดๆ ไปเราจะลงลึกในแต่ละชิ้น

แต่ก่อนจะไปถึง execution — ยังมีเรื่องสำคัญอีกหนึ่งเรื่องที่ IS auditor ต้องเข้าใจในช่วง planning คือ compliance กับกฎหมายและ regulations — เพราะ planning ที่ดีต้องรวม legal requirements เข้าไปเป็นข้อมูลตั้งต้นเสมอ

Cross-domain: แนวคิด planning ที่เรียนที่นี่จะกลับมาปรากฏใน Operations domain — D4.06 — Business Impact Analysis คือการนำ risk-based thinking ไปใช้กับ business continuity planning และ D4.08 — Business Continuity Plan คือผลลัพธ์ที่ได้จาก BIA process นั้น

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