Tensora›Insights›PDPA & Software Development
CompliancePDPASoftware Engineering

PDPA กับการพัฒนาซอฟต์แวร์
สิ่งที่ Developer ต้องรู้

พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 ไม่ใช่แค่เรื่องของฝ่ายกฎหมาย — มันส่งผลโดยตรงต่อทุก บรรทัดโค้ดที่สัมผัสข้อมูลผู้ใช้ Developer ที่ไม่รู้ PDPA คือ Developer ที่กำลังสร้างความเสี่ยงให้องค์กรโดยไม่รู้ตัว

PDPA มีผลบังคับใช้เต็มรูปแบบตั้งแต่ 1 มิถุนายน 2565 แต่หลายทีม Dev ยังคิดว่านี่คือ "เรื่องของ Legal" ความจริงคือ การออกแบบ Database Schema, API Endpoint, Logging System และ Third-party Integration ล้วนมีนัยสำคัญต่อการปฏิบัติตาม PDPA ทั้งสิ้น บทความนี้แปลกฎหมายให้กลายเป็นสิ่งที่ Engineer นำไปใช้งานได้จริง
5ล้าน
โทษปรับทางปกครองสูงสุดต่อกรณี สำหรับข้อมูลอ่อนไหว
PDPA มาตรา 82
72ชม.
เวลาที่ต้องแจ้ง PDPC เมื่อเกิด Data Breach นับจากรู้เหตุ
PDPA มาตรา 37(3)
2×
โทษทางแพ่งสูงสุด 2 เท่าของความเสียหายจริงที่เกิดขึ้น
PDPA มาตรา 77

PDPA คืออะไร และทำไม Developer ต้องสนใจ?

PDPA คืออะไร?

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (Personal Data Protection Act) คือกฎหมายไทยที่ กำหนดว่าองค์กรต้องเก็บ ใช้ และเปิดเผยข้อมูลส่วนบุคคลอย่างไร มีแนวทางคล้าย GDPR ของยุโรป แต่ปรับให้เหมาะกับบริบทไทย

ผู้ควบคุมข้อมูลผู้ประมวลผลข้อมูลเจ้าของข้อมูลPDPC

ทำไม Developer ต้องสนใจ?

เพราะ ซอฟต์แวร์คือจุดที่ข้อมูลถูกประมวลผล การออกแบบ Schema ที่เก็บข้อมูลเกินจำเป็น, API ที่ expose ข้อมูลส่วนบุคคล, หรือ Log ที่บันทึก PII โดยไม่ตั้งใจ — ล้วนเป็นการละเมิด PDPA ที่ Developer สร้างขึ้นโดยไม่รู้ตัว

Database DesignAPI SecurityLoggingThird-party SDK

ข้อมูลส่วนบุคคล vs ข้อมูลอ่อนไหว — ต่างกันอย่างไร?

PDPA แบ่งข้อมูลออกเป็น 2 ระดับ มีข้อกำหนดต่างกันชัดเจน ข้อมูลอ่อนไหวต้องการ Explicit Consent และมีโทษหนักกว่า Developer ต้องรู้ว่าระบบของตัวเองสัมผัสข้อมูลประเภทไหน
ประเภทข้อมูล
ข้อมูลส่วนบุคคลทั่วไป
ข้อมูลอ่อนไหว (Sensitive)
นิยาม
ข้อมูลที่ระบุตัวบุคคลได้
ข้อมูลที่อาจก่อให้เกิดการเลือกปฏิบัติหรืออันตราย
ตัวอย่าง
ชื่อ, อีเมล, เบอร์โทร, IP Address, เลขบัตรประชาชน, ที่อยู่, วันเกิด
เชื้อชาติ, ศาสนา, สุขภาพ/โรค, พันธุกรรม, ชีวมิติ (ลายนิ้วมือ, ใบหน้า), เพศวิถี, ประวัติอาชญากรรม, สหภาพแรงงาน, ความเห็นทางการเมือง
Consent ที่ต้องการ
Explicit หรือ Lawful Basis อื่น
Explicit Consent เท่านั้น (ยกเว้นกรณีพิเศษ)
โทษสูงสุด (ทางปกครอง)
3,000,000 บาท
5,000,000 บาท
ตัวอย่างในระบบ
ระบบ CRM, E-commerce, HR, Contact Form
ระบบ Hospital MIS, HR (ใบลาป่วย), FinTech KYC, ระบบ Biometric
สำหรับ Developer: ก่อน Sprint เริ่ม ให้ถามตัวเองว่า "Field นี้ใน Schema เราเป็น Sensitive Data ไหม?" ถ้าใช่ ต้องมีกระบวนการ Explicit Consent และการเข้ารหัสที่เข้มงวดกว่าปกติ

ฐานทางกฎหมาย 6 ประการ — ไม่ใช่แค่ Consent อย่างเดียว

Developer หลายคนคิดว่า PDPA = ต้องขอ Consent ทุกอย่าง แต่จริงๆ PDPA มีฐานทางกฎหมาย 6 ข้อ การเลือกฐานที่ถูกต้องตั้งแต่ Design Phase ส่งผลต่อทั้ง UX และสิ่งที่ต้อง implement ในระบบ
01
Consent — ความยินยอม

เจ้าของข้อมูลให้ความยินยอมอย่างชัดแจ้งและสมัครใจ ต้องสามารถถอนได้ตลอดเวลา ใช้กับข้อมูลที่ไม่มีฐานอื่นรองรับ

ตัวอย่าง: Newsletter signup, Cookie consent, Marketing email
02
Contract — สัญญา

จำเป็นต้องประมวลผลเพื่อปฏิบัติตามสัญญากับเจ้าของข้อมูล หรือดำเนินการตามคำขอก่อนทำสัญญา

ตัวอย่าง: ชื่อ-ที่อยู่สำหรับจัดส่งสินค้า, ข้อมูลการชำระเงิน, สัญญาจ้างงาน
03
Legal Obligation — หน้าที่ตามกฎหมาย

จำเป็นต้องประมวลผลเพื่อปฏิบัติตามกฎหมายที่ผู้ควบคุมข้อมูลต้องปฏิบัติตาม

ตัวอย่าง: ข้อมูลภาษี (สรรพากร), KYC ตามกฎ ธปท., รายงาน AMLO
04
Vital Interests — ผลประโยชน์สำคัญด้านชีวิต

จำเป็นต้องประมวลผลเพื่อป้องกันหรือระงับอันตรายต่อชีวิต ร่างกาย หรือสุขภาพ

ตัวอย่าง: ข้อมูลฉุกเฉินทางการแพทย์, ระบบแจ้งเตือนภัยพิบัติ
05
Public Task — ภารกิจสาธารณะ

จำเป็นต้องประมวลผลเพื่อปฏิบัติภารกิจเพื่อประโยชน์สาธารณะ หรือการใช้อำนาจรัฐ

ตัวอย่าง: ระบบทะเบียนราษฎร์, ระบบสาธารณสุขของรัฐ
06
Legitimate Interests — ผลประโยชน์อันชอบธรรม

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

ตัวอย่าง: การติดต่อ B2B Lead, Fraud detection, Network security logging

สิทธิ์ 8 ประการของเจ้าของข้อมูล — ที่ระบบต้องรองรับ

PDPA กำหนดสิทธิ์ให้เจ้าของข้อมูล 8 ประการ Developer ต้องออกแบบระบบให้มีกลไกรองรับสิทธิ์เหล่านี้ ไม่ใช่แค่เขียนไว้ใน Privacy Policy
สิทธิ์ที่ 01

สิทธิ์รับทราบ (Right to be Informed)

ต้องแจ้งให้เจ้าของข้อมูลทราบก่อนหรือขณะเก็บรวบรวม ว่าเก็บอะไร ทำไม นานแค่ไหน และแชร์ให้ใคร

Privacy NoticeConsent Form
สิทธิ์ที่ 02

สิทธิ์ขอเข้าถึง (Right of Access)

เจ้าของข้อมูลขอสำเนาข้อมูลที่เราเก็บได้ ต้องตอบกลับภายใน 30 วัน ระบบต้องสามารถ export ข้อมูลของ user คนเดียวได้

Data Export APIUser Portal
สิทธิ์ที่ 03

สิทธิ์ส่งต่อข้อมูล (Right to Data Portability)

ส่งข้อมูลในรูปแบบที่อ่านได้ด้วยเครื่อง (machine-readable) ให้เจ้าของข้อมูลหรือผู้ควบคุมรายอื่น

JSON/CSV ExportStructured Format
สิทธิ์ที่ 04

สิทธิ์คัดค้าน (Right to Object)

คัดค้านการประมวลผลข้อมูลได้ โดยเฉพาะการใช้เพื่อ Direct Marketing หรือ Profiling ระบบต้อง honour การ opt-out

UnsubscribeOpt-out Flag
สิทธิ์ที่ 05

สิทธิ์ลบข้อมูล (Right to Erasure)

"Right to be forgotten" — ขอให้ลบข้อมูลได้เมื่อไม่มีความจำเป็นต้องเก็บอีกต่อไป ต้องลบทั้งใน Primary DB, Backup, และ Log

Soft DeleteData PurgeCascade Delete
สิทธิ์ที่ 06

สิทธิ์ระงับการใช้ (Right to Restriction)

ขอให้หยุดประมวลผลข้อมูลชั่วคราวในระหว่างที่ตรวจสอบหรือโต้แย้งความถูกต้อง ต้องมี flag ระงับการใช้งาน

Processing FlagAccount Freeze
สิทธิ์ที่ 07

สิทธิ์แก้ไข (Right to Rectification)

ขอให้แก้ไขข้อมูลที่ไม่ถูกต้องหรือไม่ครบถ้วนได้ ระบบต้องมีช่องทางให้ผู้ใช้หรือเจ้าหน้าที่แก้ไขข้อมูลได้

Edit ProfileAdmin Correction
สิทธิ์ที่ 08

สิทธิ์ถอน Consent (Right to Withdraw)

ถอนความยินยอมได้ตลอดเวลาโดยง่ายเหมือนกับการให้ความยินยอม การถอนต้องไม่กระทบข้อมูลที่ประมวลผลไปแล้วก่อนถอน

Consent ManagementPreference Center

ความผิดพลาดที่ Developer มักทำ — และวิธีแก้

MISTAKE #1
Logging ข้อมูลส่วนบุคคลใน Application Log

console.log(`User login: ${user.email}, IP: ${req.ip}`) บรรทัดเดียวอาจทำให้ Email และ IP Address ของผู้ใช้ถูก log ไว้ในระบบ logging ที่มี คนหลายคนเข้าถึงได้ นี่คือการเปิดเผยข้อมูลส่วนบุคคลโดยไม่จำเป็น

❌ ทำแบบนี้ไม่ได้
Log email, ชื่อ, เลขบัตร, IP address, หรือ token ใดๆ ใน application log ที่ไม่มีการควบคุมการเข้าถึง
✓ ควรทำแบบนี้
Log เฉพาะ User ID หรือ UUID, ใช้ Log masking, จำกัดสิทธิ์การเข้าถึง Log, กำหนด retention ของ Log
MISTAKE #2
เก็บข้อมูลมากกว่าที่จำเป็น (No Data Minimization)

การเก็บ Field เผื่อไว้ก่อน เช่น เก็บ Date of Birth ทั้งที่ระบบต้องการแค่ verify ว่าอายุเกิน 18 ปีหรือไม่ หรือเก็บ ID Card Number ทั้งที่ไม่มีการใช้งาน — ถือเป็นการฝ่าฝืนหลัก Data Minimization ของ PDPA

❌ ทำแบบนี้ไม่ได้
เพิ่ม Field ใน Schema โดยไม่มี business requirement ชัดเจน, เก็บ Raw PII ทั้งที่ต้องการแค่ derived value
✓ ควรทำแบบนี้
เก็บเฉพาะข้อมูลที่มี documented purpose, ใช้ derived/calculated fields แทน Raw PII เมื่อทำได้
MISTAKE #3
ไม่มีกลไก Data Deletion และ Right to Erasure

ระบบส่วนใหญ่มีแค่ Soft Delete (set is_deleted = true) แต่ข้อมูลยังอยู่ใน Database จริงๆ รวมถึง Backup และ Log PDPA กำหนดว่าการลบต้องเป็นการลบจริง ไม่ใช่แค่ซ่อนจากหน้าจอ

❌ ทำแบบนี้ไม่ได้
Soft delete อย่างเดียว, ไม่มี data purge process, ไม่ได้ลบจาก backup และ archive
✓ ควรทำแบบนี้
มี Data Deletion Pipeline ที่ครอบคลุม Primary DB, Backup, Cache, Search Index, Log, และ Third-party ที่ share ข้อมูลไป
MISTAKE #4
ส่งข้อมูลให้ Third-party โดยไม่มี Data Processing Agreement

การ integrate Analytics SDK, Marketing Platform, หรือ Cloud Service โดยไม่ตรวจสอบว่า vendor เหล่านั้นมี DPA (Data Processing Agreement) กับองค์กรเราหรือไม่ ถือเป็นการส่งข้อมูล ให้ผู้ประมวลผลโดยไม่มีสัญญา — ผิด PDPA มาตรา 40

❌ ทำแบบนี้ไม่ได้
เพิ่ม Google Analytics, Facebook Pixel, Sentry, หรือ SDK ใดๆ ที่รับข้อมูลผู้ใช้โดยไม่มีการตรวจสอบ DPA
✓ ควรทำแบบนี้
ทำ Vendor Assessment ก่อน integrate, ขอ DPA จาก vendor, ระบุ third-party ใน Privacy Policy, ใช้ Consent Management Platform

PDPA Developer Checklist — ทำก่อน Go Live

Checklist นี้ไม่ใช่การรับประกันว่าระบบจะ compliant 100% — การตรวจสอบขั้นสุดท้ายควรทำร่วมกับ Legal และ DPO (Data Protection Officer) แต่นี่คือจุดเริ่มต้นที่ Engineer ต้องผ่านให้ได้
📐 DESIGN PHASE

ก่อนเริ่มพัฒนา

  • ระบุและ document ข้อมูลส่วนบุคคลทุกประเภทที่ระบบจะเก็บ (Data Mapping)
  • กำหนด Lawful Basis สำหรับแต่ละ data point อย่างชัดเจน
  • ออกแบบโดยยึดหลัก Data Minimization — เก็บเฉพาะสิ่งที่จำเป็น
  • กำหนด Data Retention Policy — เก็บนานแค่ไหน ลบเมื่อไหร่
  • วางแผน User Rights Flow (Access, Deletion, Export, Opt-out)
  • ทำ Vendor Assessment สำหรับ Third-party ทุกตัวที่จะรับข้อมูลผู้ใช้
⚙️ DEVELOPMENT PHASE

ระหว่างการพัฒนา

  • เข้ารหัสข้อมูลส่วนบุคคลที่ sensitive ใน Database (Encryption at Rest)
  • ใช้ HTTPS/TLS ทุก Endpoint (Encryption in Transit)
  • ไม่ log PII ใน Application Log — ใช้ User ID แทน
  • สร้าง API สำหรับ Data Export (JSON/CSV) ในระดับ User
  • สร้าง Data Deletion Pipeline ที่ครอบคลุม DB, Cache, Backup
  • Implement Consent Management — บันทึก consent พร้อม timestamp และ version
  • สร้างกลไก Withdraw Consent ที่ทำงานได้จริง
  • Mask หรือ Anonymize ข้อมูลใน Non-production environment
🚀 PRE-LAUNCH

ก่อน Go Live

  • มี Privacy Policy ที่ชัดเจน ครบถ้วน และเข้าถึงได้ง่าย
  • มี Cookie Notice / Consent Banner (ถ้าใช้ Tracking Cookies)
  • มี DPA ลงนามแล้วกับ Vendor ทุกรายที่รับข้อมูลส่วนบุคคล
  • มี Incident Response Plan สำหรับ Data Breach (แจ้ง PDPC ภายใน 72 ชม.)
  • ทดสอบ User Rights Flow จริงๆ — ขอข้อมูล, ขอลบ, ถอน Consent
  • ตั้ง Monitoring สำหรับ Unauthorized Access ต่อข้อมูลส่วนบุคคล
องค์กรที่ต้องมี DPO (Data Protection Officer): องค์กรที่ประมวลผลข้อมูลส่วนบุคคล ในปริมาณมาก, หน่วยงานราชการ, หรือองค์กรที่ประมวลผล Sensitive Data เป็นหลัก ต้องแต่งตั้ง DPO อย่างเป็นทางการ นักพัฒนาควรรู้ว่าองค์กรของตนมี DPO หรือไม่ และประสานงานกับ DPO ตั้งแต่ระยะ Design

PDPA ไม่ใช่ภาระ — มันคือ Engineering Standard ใหม่

Developer ที่เข้าใจ PDPA ไม่ได้แค่ "ไม่ทำผิดกฎหมาย" — พวกเขาสร้างระบบที่ มีคุณภาพสูงกว่า ระบบที่ออกแบบมาให้ลบข้อมูลได้จริงๆ export ได้ และควบคุม consent ได้ คือระบบที่มีสถาปัตยกรรมที่ดีกว่าโดยธรรมชาติ

จุดเริ่มต้นที่ดีที่สุดคือนำ PDPA เข้าสู่ Definition of Done ของทีม — ก่อน Story ใดๆ จะถือว่า Done ต้องตอบได้ว่า "Story นี้สัมผัสข้อมูลส่วนบุคคลไหม? ถ้าใช้ เราจัดการถูกต้องตาม PDPA แล้วหรือยัง?"

ที่ Tensora เราฝัง PDPA Awareness ไว้ในกระบวนการพัฒนาตั้งแต่ต้น ทุก Schema ที่ออกแบบ ทุก API ที่สร้าง และทุก Third-party ที่ integrate ผ่านการพิจารณาด้านความเป็นส่วนตัวก่อนเสมอ เพราะ Compliance ที่ดีที่สุดคือ Compliance ที่ build-in ตั้งแต่ Day 1 ไม่ใช่ bolt-on ทีหลัง

กำลังพัฒนาระบบที่ต้องสอดคล้องกับ PDPA?

พูดคุยกับทีม Tensora →