ความต่อเนื่องเมื่อระบบเปลี่ยน (System Change & Emerging Risk) เมื่อหน่วยงานปรับไปใช้ระบบดิจิทัล/Cloud ความเสี่ยงด้านความถูกต้องของข้อมูลเปลี่ยนไปอย่างไร การควบคุมภายในเดิมยังครอบคลุมไหม และตรวจสอบภายในต้องทดสอบการควบคุมอะไรเพิ่มขึ้น?

31 ส.ค. 2569

เมื่อหน่วยงานเปลี่ยนผ่านระบบสู่ดิจิทัลและ Cloud (Cloud Migration & Digital Transformation) บริบทของความเสี่ยงและการควบคุมภายในจะเปลี่ยนจาก “Manual & Paper-based Controls” ไปสู่ “Automated Controls & Shared Responsibility Model” อย่างสิ้นเชิง

โดยสรุปเป็น 3 มิติหลัก ดังนี้

ความเสี่ยงด้านความถูกต้องของข้อมูลเปลี่ยนไปอย่างไร? (Evolving Data Integrity Risks)

เดิมทีความถูกต้องของข้อมูล (Data Integrity) มักขึ้นอยู่กับความผิดพลาดของมนุษย์ (Human Errors) หรือการปลอมแปลงเอกสารกระดาษ แต่เมื่อเข้าสู่ระบบดิจิทัล/Cloud ความเสี่ยงจะเปลี่ยนรูปแบบเป็น

Data Ingestion & Pipeline Failure: การดึงข้อมูลจากหลายแหล่ง (เช่น ระบบย่อย ข้ามไปยัง Data Lake/Cloud Platform) อาจเกิดข้อผิดพลาดในการ Transform หรือ Sync ข้อมูลตกหล่น (Data Incompleteness) หรือข้อมูลซ้ำซ้อน (Duplication)
Shadow IT & Data Silos: หน่วยงานอาจนำข้อมูลไปประมวลผลต่อบน Cloud Application ภายนอกหรือ Google Sheets/Excel ที่ไม่ได้ควบคุม ทำให้เกิด “ข้อมูลคนละชุด (Single Source of Truth หายไป)”
Unauthorized Direct Data Modification: ความเสี่ยงจากการแก้ไขข้อมูลโดยตรงในระดับ Database หรือ Backend ผ่าน API โดยไม่มี System Log บันทึกไว้
Data Processing Layer Issues: ในสถาปัตยกรรมข้อมูลสมัยใหม่ (เช่น Medallion Architecture: Bronze Silver Gold) หาก Business Logic หรือ Data Cleansing ในแต่ละ Layer ผิดพลาด จะส่งผลกระทบเป็นลูกโซ่ต่อรายงานและ Dashboard ของผู้บริหาร

การควบคุมภายในเดิมยังครอบคลุมไหม? (Control Coverage & Gaps)

คำตอบสั้น ๆ: “ไม่ครอบคลุม” และหากพึ่งพาการควบคุมเดิม จะเกิด Control Blind Spots ทันที

การตรวจดูเอกสาร (Documentary Check) ใช้ไม่ได้ผล: การดูตราประทับหรือลายเซ็นกระดาษไม่สามารถยืนยันความถูกต้องของชุดข้อมูลในระบบ Cloud ได้
กรอบความรับผิดชอบเปลี่ยน (Shared Responsibility Model): หน่วยงานมักเข้าใจผิดว่า “ย้ายขึ้น Cloud แล้ว ผู้ให้บริการ (Cloud Provider) ดูแลความปลอดภัยและความถูกต้องทั้งหมด” แต่ในความเป็นจริง Cloud Provider ดูแลเฉพาะโครงสร้างพื้นฐาน (Security OF the Cloud) ส่วน ความถูกต้อง การเข้าถึง และการตั้งค่าข้อมูล (Security & Governance IN the Cloud) ยังคงเป็นความรับผิดชอบของหน่วยงาน
การแบ่งแยกหน้าที่แบบกายภาพหมดไป: การแบ่งงานที่เคยแยกโต๊ะ/แยกแฟ้ม ต้องเปลี่ยนมาเป็นการควบคุมผ่าน Role-Based Access Control (RBAC) และ Least Privilege Principle ในระบบดิจิทัล

ผู้ตรวจสอบภายในต้องทดสอบการควบคุมอะไรเพิ่มขึ้น? (Audit Testing Focus)

ผู้ตรวจสอบภายในต้องยกระดับการตรวจจาก Manual Compliance ไปสู่ IT General Controls (ITGC) และ Automated Application Controls (ITAC) โดยมีจุดทดสอบสำคัญดังนี้

มิติการตรวจสอบ	ประเด็นและจุดควบคุมที่ต้องทดสอบ (Audit Testing Procedures)
1. Identity & Access Governance	• ตรวจสอบการตั้งค่าสิทธิ์ (Access Matrix) ตามหลัก Least Privilege และการแบ่งแยกหน้าที่ (SoD) ในระบบ • ทดสอบการบังคับใช้ Multi-Factor Authentication (MFA) และการปิดสิทธิ์พนักงานที่ลาออก/เปลี่ยนหน้าที่ทันที (Timely Deprovisioning)
2. Interface & Data Pipeline Controls	• ทดสอบการกระทบยอดข้อมูลอัตโนมัติ (Automated Reconciliation / Hash Validation / Record Count) ระหว่างระบบต้นทาง (Source) และปลายทาง (Target/Cloud Platform) • ตรวจสอบกระบวนการ Data Pipeline Error Handling ว่าเมื่อข้อมูลเข้าไม่ครบ ระบบมีการแจ้งเตือน (Alert) และ Retry อย่างไร
3. Automated Input & Processing Controls	• ทดสอบการดักจับข้อผิดพลาดที่หน้ากรอกข้อมูล (Field Validations, Format Checks, Business Logic Rules) • ทดสอบความถูกต้องของสูตร/Algorithm ที่ระบบคำนวณอัตโนมัติ (Automated Calculations)
4. Audit Trail & Log Immutability	• ตรวจสอบว่าระบบมีการบันทึก System Logs และ Change Logs (ใคร ทำอะไร เมื่อไหร่ ค่าเดิมเป็นอะไร) • ทดสอบว่า Log ถูกจัดเก็บในพื้นที่ที่ปลอดภัย ป้องกันการแก้ไขหรือลบโดย Admin (Write-Once / Protected Log Storage)
5. Change Management & Cloud Configuration	• ตรวจสอบการควบคุมการแก้ไข Code / Config บน Cloud ว่ามีการผ่านขั้นตอนทดสอบ (UAT) และแยกสภาพแวดล้อม Development/Production ชัดเจน • ตรวจสอบการตั้งค่าความปลอดภัยของ Cloud Storage (เช่น ป้องกัน Public Access โดยไม่ได้ตั้งใจ)