PDPA กับงานบัญชี

PDPA คืออะไร -- สรุปสั้นๆ สำหรับคนทำงานบัญชี

PDPA ย่อมาจาก Personal Data Protection Act หรือ พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 บังคับใช้เต็มรูปแบบตั้งแต่วันที่ 1 มิถุนายน 2565 กฎหมายฉบับนี้คุ้มครอง "ข้อมูลส่วนบุคคล" คือข้อมูลใดๆ ที่สามารถระบุตัวบุคคลได้ ไม่ว่าจะโดยตรงหรือโดยอ้อม

สิ่งที่หลายคนไม่ทราบคือ PDPA มีบทลงโทษรุนแรง:

• โทษทางแพ่ง — ชดใช้ค่าสินไหมทดแทนตามความเสียหายจริง และศาลอาจสั่งให้ชดใช้เพิ่มได้สูงสุด 2 เท่า
• โทษทางอาญา — จำคุกสูงสุด 1 ปี และ/หรือปรับสูงสุด 1 ล้านบาท
• โทษทางปกครอง — ปรับสูงสุด 5 ล้านบาท

นั่นหมายความว่า ถ้าองค์กรจัดการข้อมูลส่วนบุคคลผิดพลาด — ไม่ว่าจะจงใจหรือประมาท — ทั้งองค์กรและผู้รับผิดชอบอาจถูกดำเนินคดีได้

และตัวเลขเหล่านี้ไม่ใช่เพดานที่เขียนไว้ในกฎหมายเฉย ๆ อีกต่อไป สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส. หรือ PDPC) แถลงในวาระครบ 4 ปีเมื่อ 26 มิถุนายน 2569 ว่าได้ตรวจสอบความพร้อมของหน่วยงานภาครัฐและเอกชนไปแล้วกว่า 590,000 หน่วยงาน และออกคำสั่งลงโทษปรับทางปกครองรวมมูลค่ากว่า 21.5 ล้านบาท โดยเคสที่ปรับสูงสุดอยู่ที่ 7 ล้านบาท จากความผิด 3 ฐานรวมกัน

ข้อมูลส่วนบุคคลที่ฝ่ายบัญชีถือ — อ่อนไหวกว่าที่คิด

ลองดูว่าฝ่ายบัญชีถือข้อมูลอะไรบ้าง และแต่ละประเภทมีความอ่อนไหวระดับไหน:

ประเภทข้อมูล	ตัวอย่าง	ระดับความอ่อนไหว
ข้อมูลพนักงาน	เลขบัตรประชาชน, เงินเดือน, บัญชีธนาคาร, ประกันสังคม	สูงมาก
ข้อมูลผู้ขาย/Vendor	เลขประจำตัวผู้เสียภาษี, ชื่อ-นามสกุล, ที่อยู่, บัญชีธนาคาร	สูง
ข้อมูลลูกค้า	ชื่อ-นามสกุล, ที่อยู่, เลขภาษี, ประวัติการซื้อ, ข้อมูลการชำระเงิน	สูง
ข้อมูลกรรมการ/ผู้ลงนาม	สำเนาบัตรประชาชน, ลายมือชื่อ, ที่อยู่ส่วนตัว	สูงมาก

จะเห็นว่าข้อมูลเหล่านี้ ไม่ใช่แค่ข้อมูลทั่วไป แต่เป็นข้อมูลที่ถ้าหลุดออกไปจะสร้างความเสียหายร้ายแรง — ตั้งแต่ถูกปลอมแปลงเอกสาร ขโมยตัวตน (Identity Theft) ไปจนถึงถูกฟ้องร้องทางกฎหมาย

5 ความเสี่ยง PDPA ที่ฝ่ายบัญชีมักมองข้าม

จากประสบการณ์ที่เราทำงานกับหลายองค์กร ทั้งภาครัฐและเอกชน ความเสี่ยงเหล่านี้เจอซ้ำแล้วซ้ำเล่า:

1. ส่งสลิปเงินเดือนทาง LINE/Email โดยไม่เข้ารหัส

หลายองค์กรยังส่งสลิปเงินเดือนผ่านแชท LINE หรือ Email แบบไม่มีรหัสผ่าน สลิปเงินเดือนมีทั้งเลขบัตรประชาชน เลขบัญชีธนาคาร และจำนวนเงินเดือน — ถ้าหลุดไปคนเดียว ก็ถือว่าละเมิด PDPA แล้ว เรื่องนี้เกี่ยวข้องโดยตรงกับความปลอดภัยของข้อมูลในระบบ ERP

2. เก็บสำเนาบัตรประชาชนในแฟ้มกระดาษ — ไม่มีระบบจัดการการเข้าถึง

สำเนาบัตรประชาชนของผู้ขาย พนักงาน กรรมการ ถูกเก็บไว้ในตู้เอกสารที่ใครก็เปิดได้ ไม่มีบันทึกว่าใครหยิบไปเมื่อไหร่ ไม่มีระบบล็อค ไม่มีการขีดฆ่า — นี่คือ ช่องโหว่ PDPA ที่อันตรายที่สุด

3. แชร์ไฟล์ Excel ข้อมูลพนักงานกันไปมา

ไฟล์ Excel ที่แชร์กันไปมาระหว่างแผนก มักมีข้อมูลเงินเดือน เลขบัตรประชาชน เลขบัญชีธนาคาร — ไม่มีการเข้ารหัส ไม่มี password ไม่มีบันทึกว่าใครเปิดดู คัดลอก หรือส่งต่อ ถ้าไฟล์หลุด ไม่มีทางรู้ว่าหลุดจากจุดไหน

4. ไม่มีนโยบายลบข้อมูลเมื่อหมดความจำเป็น (Data Retention Policy)

PDPA กำหนดว่าเมื่อไม่มีความจำเป็นต้องเก็บข้อมูลแล้ว ต้องลบหรือทำลาย แต่ในทางปฏิบัติ ฝ่ายบัญชีส่วนใหญ่เก็บเอกสารไว้ไม่มีกำหนด — สำเนาบัตรประชาชนของผู้ขายที่ไม่ได้ทำธุรกิจด้วยแล้ว 5 ปี ยังอยู่ในตู้ นี่คือความเสี่ยงที่ไม่จำเป็น

5. ให้พนักงานบัญชีทุกคนเข้าถึงข้อมูลเงินเดือนทุกระดับ — ไม่มี Access Control

ในหลายองค์กร พนักงานบัญชีทุกคนสามารถเห็นเงินเดือนของทุกคนในบริษัท ตั้งแต่พนักงานรายวันไปจนถึงผู้บริหารระดับสูง การเข้าถึงข้อมูลโดยไม่จำเป็น (Excessive Access) ก็ถือเป็น ความเสี่ยงตาม PDPA เช่นกัน เรื่องนี้สามารถป้องกันได้ด้วยระบบยืนยันตัวตนแบบ 2 ชั้น (2FA) และการกำหนดสิทธิ์ที่เหมาะสม

PDPA กำหนดอะไรบ้างที่เกี่ยวข้องกับฝ่ายบัญชี

PDPA ไม่ได้พูดถึงฝ่ายบัญชีโดยเฉพาะ แต่หลักการของกฎหมายส่งผลกระทบโดยตรงต่อการทำงานของฝ่ายบัญชีทุกข้อ:

• ต้องขอความยินยอม (Consent) — ก่อนเก็บข้อมูลส่วนบุคคลของพนักงาน ผู้ขาย หรือลูกค้า ต้องได้รับความยินยอมอย่างชัดแจ้ง ยกเว้นกรณีที่กฎหมายกำหนดให้เก็บได้ (เช่น สรรพากรกำหนดให้เก็บเอกสารภาษี)
• ต้องแจ้งวัตถุประสงค์ (Privacy Notice) — ต้องแจ้งให้เจ้าของข้อมูลทราบว่าเก็บข้อมูลไปทำอะไร เก็บนานเท่าไหร่ ใครเข้าถึงได้บ้าง
• ต้องจำกัดการเข้าถึง (Access Control) — ไม่ใช่ทุกคนในฝ่ายบัญชีต้องเห็นข้อมูลทุกอย่าง ต้องจำกัดตามหน้าที่และความจำเป็น
• ต้องมีระยะเวลาเก็บรักษา (Data Retention) — ต้องกำหนดระยะเวลาเก็บข้อมูลที่ชัดเจน และลบเมื่อครบกำหนด
• ต้องมีมาตรการป้องกัน (Security Measures) — ต้องมีมาตรการรักษาความปลอดภัยที่เหมาะสม ทั้งทางกายภาพ (ตู้ล็อค) และทางเทคนิค (การเข้ารหัส, ระบบรักษาความปลอดภัย)
• เจ้าของข้อมูลมีสิทธิขอดู แก้ไข ลบ (Data Subject Rights) — พนักงาน ผู้ขาย ลูกค้า มีสิทธิขอดูข้อมูลของตนเอง ขอแก้ไข หรือขอให้ลบได้ ฝ่ายบัญชีต้องตอบสนองคำขอเหล่านี้ได้ และตั้งแต่ 14 กันยายน 2569 สิทธินี้มีกรอบเวลาชัดเจนแล้ว (ดูหัวข้อถัดไป)

ฝ่ายบัญชีคือ Data Controller ตัวจริงขององค์กร — ถือข้อมูลอ่อนไหวมากที่สุด แต่มักเป็นแผนกสุดท้ายที่ได้รับการฝึกอบรมเรื่อง PDPA

14 กันยายน 2569: เมื่อพนักงานเก่าขอสำเนาข้อมูลของตัวเอง

ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์เกี่ยวกับการเข้าถึงและการขอรับสำเนาข้อมูลส่วนบุคคลฯ พ.ศ. 2569 ลงราชกิจจานุเบกษาวันที่ 16 กรกฎาคม 2569 และให้ใช้บังคับเมื่อพ้น 60 วันนับแต่วันประกาศ นั่นคือ 14 กันยายน 2569 ประกาศฉบับนี้เปลี่ยนสิทธิที่กฎหมายแม่เขียนไว้กว้าง ๆ ว่า "ต้องดำเนินการโดยไม่ชักช้า" ให้เป็นกรอบเวลาที่วัดผลได้

สาระที่กระทบฝ่ายบัญชีตรงที่สุด:

• ต้องแล้วเสร็จภายใน 30 วัน นับแต่วันได้รับคำขอ ขยายได้อีกไม่เกิน 30 วันหากมีเหตุจำเป็น และต้องแจ้งผู้ยื่นทราบ
• ต้องรวบรวมจากทุกระบบ ที่องค์กรรับผิดชอบ ไม่ใช่เฉพาะระบบใดระบบหนึ่ง — ถ้าข้อมูลเงินเดือนกระจายอยู่ในไฟล์หลายชุดหลายเครื่อง นี่คือจุดที่ทำให้ตอบไม่ทัน
• ต้องปกปิดข้อมูลของบุคคลที่สาม ก่อนส่งมอบ — ไฟล์เงินเดือนที่มีพนักงานทุกคนอยู่ในชีตเดียวส่งให้ผู้ยื่นไม่ได้ ต้องตัดเฉพาะรายออกมา
• ส่งทางอิเล็กทรอนิกส์ในรูปแบบปกติเรียกค่าธรรมเนียมไม่ได้ จะเก็บได้เฉพาะค่าใช้จ่ายจริงที่สมเหตุสมผล เช่น สำเนากระดาษ A4 ไม่เกินหน้าละ 1 บาท
• ต้องเก็บหลักฐานการดำเนินการไว้อย่างน้อย 2 ปี รวมถึงเหตุผลในกรณีที่ปฏิเสธคำขอ

สถานการณ์ที่ตรงกับฝ่ายบัญชีที่สุดคือพนักงานที่ลาออกไปแล้วขอสำเนาประวัติเงินเดือน สลิป และหนังสือรับรองการหักภาษี ณ ที่จ่ายย้อนหลัง ถ้าข้อมูลอยู่ในระบบเดียวและค้นด้วยรหัสพนักงานได้ งานนี้ใช้เวลาไม่กี่นาที ถ้าอยู่ในแฟ้มกระดาษปนกับไฟล์ที่ตั้งชื่อกันเอง 30 วันอาจไม่พอ รายละเอียดทั้งฉบับรวมถึงกรณีที่ปฏิเสธคำขอได้ อ่านที่ สิทธิขอสำเนาข้อมูลส่วนบุคคล PDPA 2569

หน้าที่ 2 ข้อที่ฝ่ายบัญชีมักไม่รู้ว่ามี

ความเสี่ยง 5 ข้อก่อนหน้านี้เป็นเรื่อง "ทำอะไรแล้วผิด" แต่ PDPA ยังมีหน้าที่เชิงรุกอีก 2 ข้อที่องค์กรถูกปรับเพราะไม่ได้ทำ ไม่ใช่เพราะทำผิด และในเคสที่ สคส. ปรับ 7 ล้านบาท ทั้งสองข้อนี้อยู่ในฐานความผิดด้วย

1. แจ้งเหตุละเมิดข้อมูลภายใน 72 ชั่วโมง

เมื่อมีเหตุอันควรเชื่อว่าข้อมูลส่วนบุคคลรั่วจริงและมีความเสี่ยงต่อสิทธิเสรีภาพของเจ้าของข้อมูล ผู้ควบคุมข้อมูลต้องแจ้ง สคส. โดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ทราบเหตุ และถ้าเป็นกรณีความเสี่ยงสูง ต้องแจ้งเจ้าของข้อมูลพร้อมแนวทางเยียวยาด้วย

จุดที่พลาดกันบ่อยคือ 72 ชั่วโมงนับจาก "ทราบเหตุ" ไม่ใช่นับจากวันที่สอบสวนเสร็จ ถ้าพนักงานบัญชีส่งไฟล์ผิดคนเย็นวันศุกร์แล้วเพิ่งรายงานผู้บริหารเช้าวันจันทร์ เวลาก็เดินไปเกือบหมดแล้ว องค์กรจึงต้องมีช่องทางแจ้งเหตุภายในที่ฝ่ายบัญชีใช้ได้ทันที ไม่ต้องไล่ตามสายบังคับบัญชา

2. แต่งตั้งเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO)

องค์กรที่เก็บหรือใช้ข้อมูลส่วนบุคคลจำนวนมากต้องแต่งตั้ง DPO และเผยแพร่ช่องทางติดต่อให้เจ้าของข้อมูลทราบ ในเคส 7 ล้านบาท หนึ่งในสามฐานความผิดคือไม่มี DPO ทั้งที่เก็บข้อมูลขนาดใหญ่ และ สคส. ยังประกาศกลางปี 2569 ว่าจะขยายข้อกำหนดเรื่อง DPO ให้ครอบคลุมองค์กรมากขึ้นในช่วงครึ่งปีหลัง

สำหรับองค์กรขนาดกลาง DPO มักไม่ใช่การเปิดตำแหน่งใหม่ แต่เป็นการมอบหมายคนที่มีอยู่ และคนที่ควรอยู่ในวงนั้นด้วยเสมอคือหัวหน้าฝ่ายบัญชี เพราะเป็นคนที่รู้ว่าข้อมูลอ่อนไหวขององค์กรอยู่แฟ้มไหน ตู้ไหน ระบบไหน

จ้างสำนักงานบัญชีหรือ outsource เงินเดือน — ใครรับผิดถ้าข้อมูลหลุด?

คำตอบที่หลายองค์กรไม่อยากได้ยินคือ รับผิดได้ทั้งสองฝ่าย PDPA แยกบทบาทเป็นผู้ควบคุมข้อมูล (Data Controller) คือองค์กรที่ตัดสินใจว่าจะเก็บข้อมูลไปทำอะไร และผู้ประมวลผลข้อมูล (Data Processor) คือผู้รับจ้างที่ทำตามคำสั่ง เช่น สำนักงานบัญชี ผู้ให้บริการคำนวณเงินเดือน ผู้รับจ้างทำลายเอกสาร หรือผู้ดูแลระบบ

ในเคสที่ สคส. สั่งปรับหน่วยงานภาครัฐแห่งหนึ่ง ข้อมูลราว 200,000 รายการรั่วไปขายบน Dark Web จากมาตรการความปลอดภัยที่ไม่เพียงพอ รหัสผ่านอ่อน ไม่มีการประเมินความเสี่ยง และไม่มีข้อตกลงการประมวลผลข้อมูล (DPA) ผลคือถูกปรับทั้งฝั่งผู้ควบคุมข้อมูลและฝั่งผู้ประมวลผลข้อมูล เป็นเงิน 153,120 บาทเท่ากันทั้งสองฝ่าย

สิ่งที่ฝ่ายบัญชีทำได้ทันทีมี 3 อย่าง:

• ทำ DPA กับผู้รับจ้างทุกราย — ระบุขอบเขตข้อมูลที่ส่งให้ วัตถุประสงค์ ระยะเวลา และหน้าที่แจ้งเหตุละเมิดกลับมาที่องค์กรภายในกรอบเวลาที่ทันต่อ 72 ชั่วโมง
• ส่งเท่าที่จำเป็น — ผู้รับจ้างทำบัญชีไม่จำเป็นต้องได้ไฟล์เงินเดือนทั้งบริษัทที่มีเลขบัตรประชาชนครบทุกคน ถ้างานจริงต้องการแค่ยอดรวมสำหรับลงบัญชี
• ปิดสิทธิ์เมื่อจบงาน — สัญญาจบต้องมีขั้นตอนเรียกคืนหรือทำลายข้อมูล และปิด account ที่เคยให้เข้าระบบ ไม่ใช่ปล่อยค้างไว้เพราะ "เผื่อต้องใช้อีก"

PDPA บอกให้ลบ แต่กฎหมายบัญชีบอกให้เก็บ — เอาอย่างไร?

นี่คือคำถามที่ฝ่ายบัญชีถามบ่อยที่สุด และเป็นจุดที่ทำให้หลายองค์กรเลือกทางที่ง่ายที่สุดคือ "เก็บทุกอย่างไว้ก่อน" ซึ่งกลายเป็นทางที่เสี่ยงที่สุด

ทางออกไม่ใช่การเลือกข้างระหว่างสองกฎหมาย แต่คือการแยกเอกสารเป็นชั้น ๆ ว่าชิ้นไหนมีกฎหมายบังคับให้เก็บ และชิ้นไหนเราเก็บเองเพราะความเคยชิน

เอกสาร/ข้อมูล	กฎหมายที่บังคับให้เก็บ	ระยะเวลา	เมื่อครบกำหนด
บัญชีและเอกสารประกอบการลงบัญชี	พ.ร.บ. การบัญชี พ.ศ. 2543 มาตรา 14	ไม่น้อยกว่า 5 ปีนับจากวันปิดบัญชี (อธิบดี DBD ขยายได้แต่ไม่เกิน 7 ปี)	ทำลายอย่างมีหลักฐาน ไม่ใช่กองทิ้งไว้
สำเนาบัตรประชาชนผู้ขายที่เลิกค้าขายกันแล้ว	ไม่มี	ตามวัตถุประสงค์เดิมที่แจ้งไว้ เมื่อสิ้นวัตถุประสงค์ก็สิ้นเหตุที่จะเก็บ	ลบหรือทำลาย
ไฟล์ Excel ที่ export ออกมาใช้ชั่วคราว	ไม่มี	ไม่ควรค้างอยู่ตั้งแต่แรก	ลบทันทีเมื่อใช้เสร็จ
สำเนาบัตรกรรมการที่ใช้ยื่นเอกสารครั้งเดียว	แล้วแต่เรื่องที่ยื่น	เท่าที่เรื่องนั้นยังไม่จบ	ลบ และไม่เก็บสำเนาซ้ำหลายชุด

ข้อสังเกตคือแถวที่กฎหมายบังคับให้เก็บมีแถวเดียว ที่เหลือคือของที่เก็บไว้เพราะไม่มีใครกล้าลบ การมีระบบที่กำหนดอายุข้อมูลได้จึงเปลี่ยน "ลบเมื่อครบกำหนด" จากงานที่ต้องอาศัยความจำของคน ให้เป็นงานของระบบ — และลดจำนวนไฟล์ Excelที่ลอยอยู่นอกระบบไปพร้อมกัน

ERP ช่วยจัดการ PDPA ได้อย่างไร

ปัญหาหลายอย่างข้างต้นไม่ได้เกิดจาก "คน" แต่เกิดจาก "ระบบ" ที่ไม่รองรับ ถ้ายังใช้ Excel, แฟ้มกระดาษ, LINE แชท เป็นเครื่องมือหลัก — จะปฏิบัติตาม PDPA ได้ยากมาก

ระบบ ERP ที่ออกแบบมาอย่างดีช่วยแก้ปัญหาเหล่านี้ได้โดยตรง:

ฟีเจอร์ ERP	ช่วยเรื่อง PDPA อย่างไร
Access Control / Role-Based Permission	กำหนดสิทธิ์เข้าถึงข้อมูลตามตำแหน่งและหน้าที่ — พนักงานบัญชีเจ้าหนี้เห็นเฉพาะข้อมูลผู้ขาย ไม่เห็นเงินเดือนพนักงาน
Audit Trail	บันทึกว่าใครเข้าถึงข้อมูลอะไร เมื่อไหร่ แก้ไขอะไร — ถ้าข้อมูลหลุด สามารถตรวจสอบย้อนกลับได้
Data Encryption	เข้ารหัสข้อมูลอ่อนไหว เช่น เลขบัตรประชาชน เลขบัญชีธนาคาร — แม้ฐานข้อมูลถูกเจาะ ข้อมูลก็ยังอ่านไม่ได้
Data Retention Management	ตั้งค่าลบข้อมูลอัตโนมัติเมื่อครบกำหนด — ไม่ต้องจำเอง ไม่เสี่ยงลืม
Centralized Data	ข้อมูลอยู่ที่เดียวในฐานข้อมูลกลาง ไม่กระจายในไฟล์ Excel หลายชุด — ควบคุมได้ ตรวจสอบได้ ลบได้ทันที

ระบบ บัญชีที่ดีต้องรองรับ PDPA ตั้งแต่วันแรก — ไม่ใช่แค่บันทึกตัวเลขได้ แต่ต้องปกป้องข้อมูลส่วนบุคคลที่อยู่ในระบบด้วย

Checklist: ฝ่ายบัญชีของคุณพร้อมรับ PDPA หรือยัง?

ลองตรวจสอบดูว่าองค์กรของคุณผ่านกี่ข้อ:

• มี Privacy Notice สำหรับพนักงาน ผู้ขาย และลูกค้า แล้วหรือยัง?
• สลิปเงินเดือนส่งแบบเข้ารหัส หรือยังส่งผ่าน LINE แบบไม่มีรหัสผ่าน?
• สำเนาบัตรประชาชนเก็บอย่างไร? มีระบบล็อคและบันทึกการเข้าถึงหรือไม่?
• ไฟล์ Excel ที่มีข้อมูลส่วนบุคคล มีรหัสผ่านป้องกันหรือไม่?
• มี Data Retention Policy กำหนดระยะเวลาเก็บข้อมูลหรือไม่?
• พนักงานบัญชีทุกคนเข้าถึงข้อมูลเงินเดือนของทุกคนได้จริงหรือ? (ควรจำกัดตามหน้าที่)
• ถ้าพนักงานลาออกแล้วขอให้ลบข้อมูล สามารถทำได้ภายในกี่วัน?
• มี Audit Trail บันทึกว่าใครเข้าถึงข้อมูลอะไรเมื่อไหร่หรือไม่?
• ถ้าข้อมูลรั่ววันศุกร์เย็น มีช่องทางที่ทำให้แจ้ง สคส. ทัน 72 ชั่วโมงหรือไม่?
• แต่งตั้ง DPO และเผยแพร่ช่องทางติดต่อแล้วหรือยัง?
• มี DPA กับสำนักงานบัญชี ผู้รับจ้างเงินเดือน และผู้รับจ้างทำลายเอกสารครบทุกรายหรือไม่?
• ถ้าพนักงานเก่าขอสำเนาข้อมูลของตัวเองวันนี้ รวบรวมส่งได้ครบทุกระบบภายใน 30 วันหรือไม่?

ถ้าตอบว่า "ไม่" มากกว่า 3 ข้อ — องค์กรของคุณมีความเสี่ยง PDPA สูง และควรพิจารณาปรับปรุงระบบโดยเร็ว

กรณีจริง: ข้อมูลหลุดจากงานเอกสาร ไม่ใช่จากการถูกแฮก

ในบรรดาเคสที่ สคส. สั่งปรับ มีหนึ่งเคสที่ฝ่ายบัญชีควรอ่านที่สุด โรงพยาบาลเอกชนแห่งหนึ่งถูกปรับ 1,210,000 บาท จากเวชระเบียนผู้ป่วยประมาณ 1,000 รายที่รั่วออกไป สาเหตุไม่ใช่การถูกเจาะระบบ แต่เป็นการกำกับผู้รับจ้างทำลายเอกสารไม่รัดกุม และผู้รับจ้างรายนั้นก็ถูกปรับด้วยอีก 16,940 บาท

ลองเปลี่ยนคำว่า "เวชระเบียน" เป็น "แฟ้มใบสำคัญจ่ายพร้อมสำเนาบัตรประชาชนผู้ขาย" แล้วเรื่องนี้ก็คือความเสี่ยงของฝ่ายบัญชีทุกองค์กรที่ส่งเอกสารเก่าไปทำลายข้างนอกโดยไม่มีใบรับรองการทำลาย ไม่มีคนขององค์กรอยู่ด้วย และไม่มี DPA

อีกสถานการณ์หนึ่งเกิดได้โดยไม่ต้องมีผู้รับจ้างเลย พนักงานบัญชีส่งไฟล์ Excel สรุปเงินเดือนทั้งบริษัทให้ผู้จัดการแผนกผ่าน Email แต่พิมพ์ที่อยู่ผิดไปตัวเดียว — ไฟล์ไปถึงคนนอกองค์กร

ผลที่ตามมา:

• ข้อมูลเงินเดือนพนักงานทุกคนหลุดออกไป
• เลขบัตรประชาชน เลขบัญชีธนาคาร ถูกเปิดเผย
• พนักงานที่ได้รับผลกระทบสามารถ ฟ้องร้องทั้งบริษัทและผู้รับผิดชอบ
• บทลงโทษ: ปรับสูงสุด 5 ล้านบาท + ค่าเสียหายทางแพ่ง

และนาทีที่รู้ว่าส่งผิด นาฬิกา 72 ชั่วโมงก็เริ่มเดินทันที ไม่ได้เริ่มนับตอนที่สอบสวนเสร็จ

ทั้งสองเคสมีจุดร่วมกันอย่างหนึ่ง คือความเสียหายเกิดที่ขั้นตอนการทำงานปกติ ไม่ใช่ที่การโจมตีจากภายนอก ถ้าใช้ระบบ ERP ที่มี Access Control พนักงานบัญชีจะเข้าถึงเฉพาะข้อมูลที่จำเป็น และไม่สามารถ export เงินเดือนทั้งบริษัทออกมาเป็นไฟล์เดียวได้ตั้งแต่แรก — ไฟล์ที่ไม่มีอยู่ ส่งผิดคนไม่ได้

สรุป

ฝ่ายบัญชีคือแผนกที่ถือข้อมูลส่วนบุคคลมากที่สุดในองค์กร — แต่มักเป็นแผนกที่ได้รับการดูแลเรื่อง PDPA น้อยที่สุด ความเสี่ยงไม่ได้อยู่ที่ "คน" ทำผิดจงใจ แต่อยู่ที่ "ระบบ" ไม่รองรับ — ส่งข้อมูลผ่านช่องทางไม่ปลอดภัย เก็บเอกสารโดยไม่มีระบบจัดการ ไม่มี Access Control

ระบบ ERP ที่ออกแบบมาอย่างดีช่วยให้ฝ่ายบัญชีปฏิบัติตาม PDPA ได้โดยอัตโนมัติ — ไม่ต้องเพิ่มภาระงาน ไม่ต้องจำเอง ระบบจัดการให้

หากองค์กรของท่านกำลังกังวลเรื่อง PDPA หรือต้องการระบบบัญชีที่ปลอดภัย สามารถนัดหมาย Demo ระบบ Saeree ERP หรือปรึกษาทีมผู้เชี่ยวชาญจาก Grand Linux Solution ได้

แหล่งอ้างอิง

1. ราชกิจจานุเบกษา. "พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562." https://www.ratchakitcha.soc.go.th
2. กระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม. "PDPA." https://www.mdes.go.th
3. สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.). "ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล." https://www.pdpc.or.th
4. Telecom Lover. "สคส. ครบรอบ 4 ปี — สรุปผลบังคับใช้ PDPA (26 มิถุนายน 2569)." telecomlover.com
5. PDPA Thailand. "สรุปเหตุการณ์ PDPA ปรับจริง — เคสภาครัฐและเอกชน." pdpathailand.com
6. PDPA Thailand. "หนังสือแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล — กรอบเวลา 72 ชั่วโมง." pdpathailand.com
7. กรมพัฒนาธุรกิจการค้า. "พระราชบัญญัติการบัญชี พ.ศ. 2543 (มาตรา 14 การเก็บรักษาบัญชีและเอกสารประกอบการลงบัญชี)." dip.go.th