ความต่อเนื่องเมื่อระบบเปลี่ยน (System Change & Emerging Risk) เมื่อหน่วยงานปรับไปใช้ระบบดิจิทัล/Cloud ความเสี่ยงด้านความถูกต้องของข้อมูลเปลี่ยนไปอย่างไร การควบคุมภายในเดิมยังครอบคลุมไหม และตรวจสอบภายในต้องทดสอบการควบคุมอะไรเพิ่มขึ้น?
31 Aug 2026
เมื่อหน่วยงานเปลี่ยนผ่านระบบสู่ดิจิทัลและ 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 โดยไม่ได้ตั้งใจ) |