ECM กับการออกแบบระบบจัดการเอกสารให้สอดคล้อง PDPA สำหรับธุรกิจประกันและบริการทางการเงิน
ธุรกิจประกันชีวิต ประกันภัย ธนาคาร และบริการทางการเงิน ต้องจัดเก็บและประมวลผล ข้อมูลส่วนบุคคล (Personal Data) จำนวนมาก ตั้งแต่ชื่อ-นามสกุล เลขประจำตัวประชาชน ข้อมูลติดต่อ ข้อมูลบัญชี ไปจนถึง ข้อมูลส่วนบุคคลที่มีความอ่อนไหว (Sensitive Personal Data) เช่น ข้อมูลสุขภาพและประวัติการรักษาพยาบาล
ข้อมูลเหล่านี้ไม่ได้อยู่เฉพาะใน Database แต่ยังอยู่ใน PDF, แบบคำขอ, กรมธรรม์, ใบเคลม, Medical Certificate, Financial Document และเอกสารอื่นที่จัดเก็บในระบบ Document Management System (DMS) หรือ Enterprise Content Management (ECM)
ดังนั้น การออกแบบ ECM/DMS ให้สนับสนุน PDPA ไม่ควรหยุดอยู่เพียงคำถามว่า “ใครเปิดเอกสารได้?” แต่ต้องครอบคลุมตั้งแต่
การจัดเก็บ → การเข้ารหัส → การค้นหา → การเข้าถึง → การแสดงผล → API → Audit → Retention & Disposal
ภายใต้แนวคิด Privacy & Security by Design
PDPA ไม่ใช่เพียงเรื่องของ Encryption
แม้ข้อมูลส่วนบุคคลจะถูก Encryption ใน Database แต่หาก Search Engine นำข้อมูลนั้นไปสร้าง Index หรือผู้ใช้งานสามารถค้นหาเอกสารทั้งหมดด้วยเลขประจำตัวประชาชน ความเสี่ยงในการเปิดเผยข้อมูลก็ยังคงอยู่
เช่นเดียวกัน หาก Metadata ถูกป้องกันอย่างดี แต่ระบบทำ Full-text Index เอกสาร Medical Certificate หรือผลตรวจสุขภาพ ข้อมูล Sensitive Personal Data ภายในเอกสารก็อาจถูกค้นพบได้
ดังนั้น Encryption เพียงอย่างเดียวไม่เพียงพอ
ECM/DMS ควรได้รับการออกแบบอย่างน้อย 5 Control Layers:
Data Classification → Encryption → Search Protection → Access & Masking → Retention & Audit
1. จำแนกข้อมูลก่อนกำหนดมาตรการป้องกัน
Metadata และ Document ควรถูกจำแนกตามประเภทและความเสี่ยง
Business Data — ใช้ค้นหาได้
เช่น Application No., Policy No., Claim No., Case No., Document Type, Document Date และ Status ซึ่งเป็น Business Identifier ที่จำเป็นต่อการค้นหาและดำเนินงาน
Personal Data — ต้องได้รับการป้องกัน
เช่น ชื่อ-นามสกุล, National ID, Passport Number, เบอร์โทรศัพท์, Email และเลขบัญชีธนาคาร
ควรพิจารณา Encryption, Masking, Access Control และจำกัดการ Search ตามความจำเป็น
Sensitive Personal Data — ควบคุมเข้มงวด
เช่น ข้อมูลสุขภาพ ประวัติการรักษา ผลตรวจทางการแพทย์ Medical Certificate และข้อมูลชีวภาพ
ควรได้รับมาตรการที่เข้มงวดมากขึ้นทั้ง Encryption, Access Control, Search, Audit และ Retention
2. ค้นหาด้วย Business Identifier แทนข้อมูลส่วนบุคคล
หลักการสำคัญคือ
“ค้นหาเอกสารด้วยข้อมูลทางธุรกิจ และเปิดเผยข้อมูลส่วนบุคคลเฉพาะเมื่อจำเป็นและได้รับสิทธิ์”
แทนที่จะออกแบบเป็น
National ID → Search → เอกสารทั้งหมดของบุคคล
ควรใช้ Business Identifier เช่น
- Application No. → เอกสารประกอบใบสมัคร
- Policy No. → เอกสารกรมธรรม์
- Claim No. → เอกสารการเคลม
- Case No. → เอกสารที่เกี่ยวข้องกับ Case
เมื่อพบเอกสารแล้วจึงตรวจสอบสิทธิ์ก่อนแสดง Metadata และ Content
แนวทางนี้ช่วยลดการใช้ข้อมูลส่วนบุคคลเป็น Universal Search Key และสนับสนุน Data Minimization, Purpose Limitation และ Need-to-Know
3. ไม่ใช่ข้อมูลทุกอย่างที่จัดเก็บ จำเป็นต้องค้นหาได้
องค์กรควรกำหนด Search & Indexing Policy ให้ชัดเจน
Searchable
- Application No.
- Policy No.
- Claim No.
- Case No.
- Document Type
- Document Date
- Status
Non-Searchable by Default
- National ID
- Passport Number
- Bank Account
- Health Information
- Medical Diagnosis
- Sensitive Personal Data
หลักการไม่ใช่ว่า PDPA “ห้าม Search Personal Data” แต่ต้องถามว่า
มี Business Purpose ที่จำเป็นจริงหรือไม่ที่ข้อมูลนั้นต้อง Search ได้?
หากไม่มี ควรเลือกแนวทาง Non-Indexed by Default
4. ระวัง Personal Data ภายใน Document Content
แม้ Metadata จะไม่มี Sensitive Data แต่ข้อมูลอาจอยู่ภายใน PDF เช่น Medical Certificate ซึ่งอาจมีชื่อผู้เอาประกัน National ID โรงพยาบาล Diagnosis หรือประวัติการรักษา
หาก ECM/DMS Extract Text แล้วส่งข้อมูลทั้งหมดไปสร้าง Search Index เท่ากับ Sensitive Data ถูกทำสำเนาไปยัง Search Infrastructure อีกชุดหนึ่ง
Document Class ที่มี Sensitive Personal Data และไม่มีความจำเป็นต้องค้นหาเนื้อหาภายใน จึงควรพิจารณา
Content Full-text Indexing = OFF
และค้นหาผ่าน Business Metadata แทน
5. Encryption ต้องทำงานร่วมกับ Access Control และ Masking
ECM/DMS ควรใช้แนวคิด Defense in Depth
- Encryption in Transit — ใช้ TLS ระหว่าง Application, API และ ECM/DMS
- Encryption at Rest — ป้องกัน Database, Content Store, Object Storage และ Backup
- Field/Property Encryption — พิจารณาเพิ่มสำหรับ Metadata ที่มีความเสี่ยงสูง
แต่ต้องเข้าใจว่า
Encryption ≠ Authorization ≠ Masking
Encryption ป้องกันข้อมูลที่จัดเก็บ, Authorization กำหนดว่าใครเข้าถึงได้ และ Masking กำหนดว่าผู้ที่เข้าถึงแล้วควรเห็นข้อมูลมากเพียงใด
6. แสดงข้อมูลตาม Role, Purpose และ Need-to-Know
ผู้ที่เปิดเอกสารได้ ไม่จำเป็นต้องเห็นข้อมูลทั้งหมด
ตัวอย่าง National ID จริง:
1234567890123
เจ้าหน้าที่ทั่วไปอาจเห็นเพียง:
xxxxxxxxx0123
เฉพาะ Role ที่มี Business Purpose และได้รับ Authorization จึงสามารถเห็นข้อมูลเต็มได้
หลักการนี้สามารถใช้กับ National ID, Passport, Bank Account, Telephone, Email, Health Information และ Financial Information
รวมถึงควรแยกแนวคิด
System Administration ≠ Personal Data Access
ผู้ดูแลระบบอาจต้องดูแล Infrastructure และ Platform แต่ไม่จำเป็นต้องเห็นข้อมูลส่วนบุคคลของลูกค้า
7. API ต้องได้รับการควบคุมเช่นเดียวกับ UI
องค์กรขนาดใหญ่มักเรียกเอกสารจาก ECM/DMS ผ่านหลายระบบ เช่น Core Insurance, Claims System, Mobile Application, Customer Portal, Partner Portal หรือ Workflow/BPM
ดังนั้น การทำ Masking เฉพาะบน Web UI ยังไม่เพียงพอ
ควรพิจารณา Business API / PDPA Control Layer เพื่อควบคุม
- Authentication & Authorization
- Data Masking
- Purpose Control
- Data Minimization
- API Policy
- Audit & Logging
ตัวอย่าง Repository อาจจัดเก็บ National ID เต็ม แต่ API สำหรับ Call Center ส่งกลับเพียง xxxxxxxxx0123
เฉพาะ Application หรือ User ที่ได้รับสิทธิ์จึงสามารถเข้าถึงข้อมูลเต็มได้
8. ทุกการเข้าถึงข้อมูลสำคัญควรตรวจสอบย้อนหลังได้
Audit Trail ควรสามารถตอบได้ว่า
WHO → accessed WHAT → WHEN → through WHICH SYSTEM → performed WHAT ACTION
เช่น View Personal Data, Unmask Personal Data, View Sensitive Data, Download/Export Document, Update Metadata และ Delete Document
Audit Log เองก็ควรยึดหลัก Data Minimization เช่น บันทึก
User A → VIEW_NATIONAL_ID → APP001 → SUCCESS
โดยไม่จำเป็นต้องบันทึก National ID จริงซ้ำลงใน Log
9. กำหนด Retention และ Secure Disposal ตั้งแต่ต้น
องค์กรต้องตอบได้ว่า “ข้อมูลนี้จำเป็นต้องเก็บไว้นานเท่าใด?”
ECM/DMS จึงควรรองรับ
Document Classification → Retention Policy → Legal Hold → Expiration → Secure Disposal
ระยะเวลาการจัดเก็บอาจขึ้นกับกฎหมาย หน่วยงานกำกับ สัญญา Business Requirement หรือ Legal Hold
การใช้สิทธิขอลบข้อมูลจึงไม่ได้หมายความว่าต้องลบเอกสารทุกประเภททันที หากองค์กรยังมีฐานกฎหมายหรือเหตุผลที่อนุญาตให้เก็บรักษาข้อมูลต่อไป
จาก Document Management สู่ Secure Content Repository
แนวคิดของ ECM/DMS สำหรับองค์กรที่จัดเก็บข้อมูลส่วนบุคคลควรเปลี่ยนจาก
“เก็บเอกสารทั้งหมดไว้ในที่เดียว และค้นหาได้ทุกอย่าง”
ไปสู่
“จัดเก็บอย่างปลอดภัย ค้นหาเฉพาะสิ่งที่จำเป็น แสดงผลตามสิทธิ์ และตรวจสอบย้อนหลังได้”
โดยสามารถสรุป Architecture ได้เป็น 5 Control Layers:
- Content & Data Classification — จำแนก Business Data, Personal Data และ Sensitive Personal Data
- Encryption & Infrastructure Security — ป้องกัน Metadata, Document, Database, Storage และ Backup
- Search Protection — Index เฉพาะข้อมูลที่จำเป็น และป้องกันข้อมูลส่วนบุคคลจากการถูก Search โดยไม่มี Business Purpose
- Access, Masking & API Control — ควบคุมตาม Role, Purpose และ Need-to-Know ทั้ง UI และ API
- Audit, Retention & Governance — ตรวจสอบย้อนหลัง กำหนดระยะเวลาเก็บรักษา Legal Hold และ Secure Disposal
เทคโนโลยีเป็นส่วนหนึ่งของ PDPA Compliance
การมี ECM/DMS ที่ออกแบบตามหลักข้างต้น ไม่ได้หมายความว่าการติดตั้ง Software เพียงอย่างเดียวทำให้องค์กร PDPA Compliant โดยอัตโนมัติ
องค์กรยังต้องมี Legal Basis, Privacy Notice, Data Retention Policy, Data Subject Rights Process, Data Processing Agreement, Breach Management รวมถึง Policies, Processes และ People Controls ที่เกี่ยวข้อง
ECM/DMS คือส่วนสำคัญของ Technical & Security Controls ที่ช่วยให้นโยบาย Privacy ขององค์กรถูกนำมาบังคับใช้กับเอกสารและ Content ได้จริง
beflex ECM: Secure Enterprise Content Management
สำหรับองค์กรที่ต้องการนำแนวคิด Privacy & Security by Design มาประยุกต์ใช้กับการบริหารเอกสาร beflex ECM สามารถออกแบบเป็น Secure Content Repository ที่รองรับ
- Enterprise Document & Content Management
- Metadata & Content Classification
- Role-based Access Control และ Data Masking
- Encryption และ Search Protection
- API Integration และ Audit Trail
- Retention, Legal Hold และ Secure Disposal
- Workflow & Approval
- Integration กับ Core Business Systems
เหมาะสำหรับองค์กรที่มีการจัดเก็บข้อมูลส่วนบุคคลจำนวนมาก โดยเฉพาะ ประกันชีวิต ประกันภัย ธนาคาร และบริการทางการเงิน
ระบบธุรกิจสามารถใช้ Application No., Policy No., Claim No. หรือ Business Identifier ในการค้นหา ขณะที่ ECM ทำหน้าที่ จัดเก็บ ปกป้อง ควบคุมสิทธิ์ และบริหารวงจรชีวิตของเอกสาร
beflex ECM — จัดเก็บปลอดภัย ค้นหาเท่าที่จำเป็น แสดงผลตามสิทธิ์ ตรวจสอบย้อนหลังได้ และบริหารข้อมูลตลอดวงจรชีวิต
ติดต่อขอคำปรึกษา —> CLICK
B Circle Co., Ltd.
Enterprise Content Management • Business Process Management • Digital Transformation
