Article 5 — 7 หลักการพื้นฐานของการประมวลผลข้อมูล#

ใน EP.26 ผมเคยพูดถึง 5 หลักการของ Article 5 ในมุม technical. EP นี้ขอเล่าให้ครบทั้ง 7 ในมุม legal ครับ

1. Lawfulness, fairness and transparency (ถูกกฎหมาย เป็นธรรม โปร่งใส) — ประมวลผลข้อมูลได้ต่อเมื่อมี ฐานทางกฎหมาย (lawful basis — จะคุยในหัวข้อ 4) + แจ้งให้เจ้าของข้อมูลรู้ว่าจะทำอะไรกับข้อมูล
2. Purpose limitation (จำกัดวัตถุประสงค์) — เก็บเพื่อ A ห้ามเอาไปใช้ B โดยไม่ขอใหม่
3. Data minimisation (เก็บน้อยที่สุด) — เก็บเท่าที่จำเป็น ไม่เก็บเผื่อ
4. Accuracy (ความถูกต้อง) — ข้อมูลต้องถูกต้องและเป็นปัจจุบัน. ถ้าผิด ต้องแก้
5. Storage limitation (จำกัดเวลาเก็บ) — เก็บได้แค่เท่าที่จำเป็น พ้นเวลาต้องลบ
6. Integrity and confidentiality (security) — ปกป้องข้อมูลจาก unauthorized access / loss / breach
7. Accountability (รับผิดชอบได้) — บริษัทต้อง พิสูจน์ได้ ว่าทำตาม 6 ข้อข้างต้น. ถ้า DPC ขอดูเอกสาร ต้องมีให้ดู

ข้อที่ 7 สำคัญที่สุดในมุมผู้บริหารครับ — เพราะมัน flip ภาระการพิสูจน์. เมื่อก่อน DPC ต้องพิสูจน์ว่าบริษัททำผิด. หลัง GDPR — บริษัทต้องพิสูจน์ว่าทำถูก. ถ้าพิสูจน์ไม่ได้ = ผิด

มุมผู้บริหาร — Article 5 ข้อ 7 (Accountability): ถ้าบริษัทคุณไม่มีเอกสาร data inventory / consent log / privacy policy ที่ผ่าน review / DPIA report — เมื่อโดน audit หรือ breach แล้วถูกถาม — คุณ default ผิด ไม่ใช่ default ถูก. การลงทุนใน documentation = การลงทุนใน defensibility

Article 6 — 6 ฐานทางกฎหมายในการประมวลผล#

หัวใจของ GDPR คือ — บริษัทห้ามเก็บ/ใช้ข้อมูลส่วนบุคคล เว้นแต่จะมี 1 ใน 6 ฐานทางกฎหมายนี้

จะลงรายละเอียดในหัวข้อ 4. ตอนนี้รู้ก่อนว่าทุกการประมวลผลต้องมี lawful basis อย่างชัดเจน — ห้ามทำเฉยๆ เพราะคิดว่ามีประโยชน์

Article 33 — แจ้ง breach ภายใน 72 ชั่วโมง#

ถ้าบริษัทเกิด personal data breach — ต้องแจ้ง supervisory authority (เช่น DPC ของไอร์แลนด์, CNIL ของฝรั่งเศส) ภายใน 72 ชั่วโมงหลังรู้ตัว. ถ้า breach น่าจะมีผลกระทบสูงต่อเจ้าของข้อมูล — ต้องแจ้ง เจ้าของข้อมูล ด้วย

72 ชั่วโมง — เป็นกฎที่ทั่วโลกยืมไปใช้ ทั้ง PDPA ไทย / CCPA แคลิฟอร์เนีย / ในหลายประเทศ. เป็นเหตุผลที่บริษัทใหญ่ต้องมี incident response team พร้อม 24/7 — เพราะถ้าเกิดตอนตี 2 วันศุกร์ ยังต้องนับเริ่มทันที

เคส Cambridge Analytica 2018 — catalyst ที่ทำให้ GDPR เริ่มถูกบังคับใช้จริง#

ก่อน GDPR บังคับใช้แค่ 2 เดือน — เกิดเรื่องที่เปลี่ยนสายตาทั่วโลก. Cambridge Analytica บริษัท political consulting ของ UK ใช้ app บน Facebook เก็บข้อมูลของผู้ใช้ + เพื่อนของผู้ใช้ (ผ่าน Facebook API เก่า) — ได้ข้อมูลของ 87 ล้านคน โดยไม่ได้ขอ consent. ข้อมูลนี้ถูกเอาไปใช้ทำ micro-targeting ทางการเมือง ใน US election 2016 + Brexit referendum

ผลกระทบ:

• Facebook โดนปรับ $5 พันล้าน โดย FTC ของ US (กฎหมาย US ไม่ใช่ GDPR — แต่ค่าปรับใหญ่ที่สุดในประวัติศาสตร์ FTC)
• Cambridge Analytica ปิดบริษัท หลังกระแสกระทบลามตัวเอง
• ทั่วโลกเริ่มเข้าใจว่า “free service” ไม่ใช่ free — เราจ่ายด้วยข้อมูล
• GDPR ที่บังคับใช้พฤษภาคม 2018 ได้ momentum มหาศาล

Cambridge Analytica ไม่ใช่ GDPR case ตรงๆ (เกิดก่อน GDPR บังคับใช้) — แต่เป็น catalyst ที่ทำให้ regulator ทั่วโลกเริ่มออก action จริง

เคส Marriott 2018 — £18.4M ICO fine ที่สอนเรื่อง M&A due diligence#

พฤศจิกายน 2018 — Marriott International ประกาศ — ระบบ Starwood reservation database (ที่ Marriott ซื้อปี 2016) โดน breach ตั้งแต่ 2014 — ก่อน Marriott จะซื้อ Starwood. ข้อมูลรั่ว ~339 ล้าน records ทั่วโลก รวมข้อมูลผู้ใช้ EU จำนวนมาก

ICO (Information Commissioner’s Office — supervisory authority ของ UK) ปรับ Marriott £18.4 ล้าน ในปี 2020 (ลดจาก £99 ล้านที่เสนอตอนแรกเพราะ COVID + ความร่วมมือ). เหตุผล:

• Marriott ไม่ทำ due diligence ที่เพียงพอ ใน security posture ของ Starwood ตอนซื้อ
• Breach อยู่ในระบบมาแล้ว 4 ปีก่อนตรวจเจอ — ขาด detection capability
• ไม่ปฏิบัติตาม Article 32 (security of processing) ของ GDPR

บทเรียน — GDPR ไม่ได้สิ้นสุดที่เซ็นสัญญาซื้อบริษัท. การควบรวมกิจการ = การควบรวม liability ของข้อมูล. ถ้าบริษัทที่ซื้อมี breach ฝังอยู่ คุณรับ liability ทั้งหมด

มุมผู้บริหาร — M&A และ privacy liability: เวลาซื้อบริษัท — data due diligence สำคัญพอๆ กับ financial due diligence. ถามให้ครบ — บริษัทเป้าหมายเคย breach ไหม? มี data inventory ไหม? consent log ไหม? ถ้าตอบไม่ได้ — คุณกำลังซื้อ landmine มาฝังในบ้าน

มาตรา 6 — ฐานทางกฎหมายในการประมวลผล#

ขนานกับ Article 6 ของ GDPR. กำหนด 6 ฐานที่เก็บ/ใช้ข้อมูลส่วนบุคคลได้ (รายละเอียดในหัวข้อ 4)

มาตรา 19-25 — สิทธิ์ของเจ้าของข้อมูล#

มาตรา 19-25 ครอบคลุม สิทธิ์ 7-8 ข้อ ของเจ้าของข้อมูล (data subject rights) — ขนานกับ Chapter III ของ GDPR. รายละเอียดในหัวข้อ 3

มาตรา 37 — แจ้ง breach ภายใน 72 ชั่วโมง#

เหมือน Article 33 ของ GDPR เลย — ถ้าเกิด breach ต้องแจ้ง PDPC (สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล) ภายใน 72 ชั่วโมง. ถ้ามี high risk ต่อเจ้าของข้อมูล — ต้องแจ้งเจ้าของข้อมูลด้วย

ค่าปรับ PDPA — สูงสุด 5 ล้านบาท + ติดคุกได้#

PDPA มี 3 ระดับโทษ

1. โทษทางปกครอง — ปรับสูงสุด 5 ล้านบาท ต่อกรณี (มาตรา 82-90)
2. โทษทางอาญา — กรณีร้ายแรง เช่น ใช้ข้อมูล sensitive โดยไม่มีฐานทางกฎหมาย ทำเพื่อหาประโยชน์ผิดกฎหมาย หรือทำให้ผู้อื่นเสียหายร้ายแรง — ติดคุกได้ถึง 1 ปี + ปรับถึง 1 ล้านบาท (มาตรา 79-81)
3. โทษทางแพ่ง — เจ้าของข้อมูลฟ้องเรียกค่าเสียหายได้ + ค่าเสียหายเชิงลงโทษ (punitive damages) สูงสุด 2 เท่า ของค่าเสียหายจริง (มาตรา 77-78)

5 ล้านบาทดูไม่เยอะถ้าเทียบกับ €20 ล้านของ GDPR. แต่ 5 ล้านบาทต่อกรณี — ถ้าบริษัทมี 100 กรณีก็ 500 ล้านบาท. และที่หนักกว่าเงิน — โทษ อาญา ที่ทำให้ผู้บริหาร ติดคุกได้

เคส LINE Thailand 2024 — model incident response ตาม PDPA#

พฤศจิกายน 2024 — LINE Thailand ตรวจพบว่า third-party vendor ที่ใช้ในระบบ customer support ถูก compromise — ข้อมูลผู้ใช้บางส่วนรั่ว (ชื่อ เบอร์ อีเมล ประวัติติดต่อ support — ไม่รวม chat content)

LINE ทำ 4 อย่างทันที:

1. แจ้ง PDPC ภายใน 72 ชั่วโมง ตามมาตรา 37
2. ออกประกาศต่อสาธารณะ + แจ้งลูกค้าที่ได้รับผลกระทบ โดยตรง
3. เปิดสายให้ติดต่อ + FAQ ให้ลูกค้าสอบถามและตรวจสอบสถานะ
4. ตัด vendor + audit chain — ตรวจสอบ third-party ที่เหลือทั้งหมดทันที

นี่คือ model incident response ของ PDPA ที่บริษัทขนาดใหญ่เริ่มทำเป็นมาตรฐาน — ตรงไปตรงมา รวดเร็ว สื่อสารชัด. แทนที่จะปิดข่าวแล้วถูกขุดมาทีหลัง — เปิดเลย แจ้งครบ ตามขั้นตอนกฎหมาย

PDPC ไม่ได้ออก fine ในเคสนี้ (ตามรายงานสาธารณะ ณ ต้นปี 2026) — เพราะการแจ้งและการ remediate เป็นไปตามที่กฎหมายกำหนด

มุมผู้บริหาร — PDPA และ vendor risk: breach ของ vendor = breach ของบริษัทคุณในสายตา PDPA. คุณคือ data controller — แม้ vendor จะเป็นคนทำพัง คุณยังรับผิดต่อเจ้าของข้อมูล. การมี DPA (Data Processing Agreement) ที่ครบ + audit right ใน contract + vendor risk management ไม่ใช่ทางเลือก — เป็น defensibility ที่จำเป็น

Controller vs Processor — คำคู่ที่ต้องแยกให้ออก#

ก่อนไปต่อ — ขอแนะนำคำคู่ที่ทั้ง GDPR และ PDPA ใช้

• Data Controller (ผู้ควบคุมข้อมูล) = บริษัทที่ ตัดสินใจ ว่าจะเก็บข้อมูลอะไร เพื่อทำอะไร — มีอำนาจตัดสินใจหลัก
• Data Processor (ผู้ประมวลผลข้อมูล) = บริษัทที่ รับจ้างทำ ตามคำสั่งของ controller — เช่น cloud provider / email marketing tool / customer support outsource

LINE = controller. Vendor ที่โดน breach = processor. Controller รับผิดต่อเจ้าของข้อมูลเป็นหลัก — processor รับผิดในขอบเขตที่ตัวเองทำพัง (เช่น breach security)

ตำแหน่งสำคัญ — เพราะกำหนดว่า ใครต้องทำอะไร ในกระบวนการตามกฎหมาย

Cluster 1 — “ของฉัน — ฉันอยากดู / แก้ / หยุด / ลบ”#

ฉาก — ลูกค้าโทรมาบอก “อยากรู้ว่าร้านคุณเก็บอะไรของฉัน — แก้ที่ผิด — หยุดใช้ — หรือลบทั้งหมด”. 4 สิทธิ์ในกลุ่มนี้ทำงานเป็นชุดเดียวกัน — เกี่ยวกับ การควบคุมข้อมูลที่ยังอยู่ในระบบ

สิทธิ์ที่ 1 — Right to Access (สิทธิ์ในการเข้าถึง)#

ชาวเมืองมีสิทธิ์ถามคุณว่า — “บริษัทมีข้อมูลอะไรของฉันบ้าง? เก็บเพื่ออะไร? share ให้ใคร?”. คุณต้องตอบครบ + ส่ง copy ของข้อมูล ให้ฟรี (อย่างน้อยครั้งแรก)

• GDPR: Article 15
• PDPA: มาตรา 30

ลองนึกฉาก — ลูกค้าโทรมาขอ “ข้อมูลทั้งหมดของฉัน”. ถ้าคุณไม่มี data inventory — คุณไม่รู้ด้วยซ้ำว่าตัวเองมีข้อมูลอะไร แล้วจะตอบยังไง?

สิทธิ์ที่ 2 — Right to Rectification (สิทธิ์ในการแก้ไข)#

ถ้าข้อมูลผิด — ชาวเมืองมีสิทธิ์ขอให้แก้

• GDPR: Article 16
• PDPA: มาตรา 36

ฟังดูง่าย แต่ในทางปฏิบัติ — ถ้าข้อมูลกระจายอยู่ใน 7 ระบบ + ส่งให้ vendor 3 ราย — แก้ที่ต้นทางอย่างเดียวไม่พอ ต้อง แจ้ง downstream ทั้งหมดให้แก้ตาม ด้วย

สิทธิ์ที่ 3 — Right to Erasure / Right to be Forgotten (สิทธิ์ในการลบ)#

ชาวเมืองมีสิทธิ์ขอให้บริษัท ลบข้อมูลของตัวเอง — โดยเฉพาะเมื่อ:

• ข้อมูลไม่จำเป็นต่อวัตถุประสงค์เดิมแล้ว

• ถอน consent + ไม่มีฐานกฎหมายอื่น

• ประมวลผลผิดกฎหมาย

• GDPR: Article 17

• PDPA: มาตรา 33

ข้อยกเว้น — กฎหมายอื่นบังคับให้เก็บ (เช่น สรรพากร / KYC / AML ของแบงก์) สามารถ “ห้ามลบ” ในส่วนนั้นได้

ในทางปฏิบัติ — สิทธิ์นี้น่าจะ ยากที่สุด สำหรับบริษัท. เพราะข้อมูลกระจาย + backup ที่ทับไม่ได้ + ระบบเก่าที่ไม่มี delete function. ต้องมี process ที่ทำได้จริงในกรอบเวลาที่กฎหมายกำหนด

สิทธิ์ที่ 4 — Right to Restriction (สิทธิ์ในการระงับการใช้)#

ระหว่างที่กำลัง dispute กับบริษัท (เช่น โต้แย้งความถูกต้อง / กำลังพิจารณาว่าจะลบไหม) — ชาวเมืองขอให้ หยุดใช้ ข้อมูลไว้ก่อน. บริษัทยังเก็บได้ — แต่ห้าม process

• GDPR: Article 18
• PDPA: ครอบในมาตรา 34-36

Cluster 2 — “ของฉัน — ฉันอยากเอาคืน / ถอน”#

ฉาก — ลูกค้าโทรมาบอก “ผมจะย้ายไปร้านอื่น — ขอเอาข้อมูลของผมไปด้วย — และถอน consent ที่เคยให้”. 2 สิทธิ์ในกลุ่มนี้เกี่ยวกับ การพาข้อมูลของตัวเองออกไป

สิทธิ์ที่ 5 — Right to Data Portability (สิทธิ์ในการพกพาข้อมูล)#

ชาวเมืองมีสิทธิ์ขอข้อมูลของตัวเองใน รูปแบบที่อ่านได้ด้วยเครื่อง (เช่น JSON / CSV) เพื่อ ย้ายไปบริษัทอื่น

• GDPR: Article 20
• PDPA: มาตรา 31

นึกเหมือนการย้ายเบอร์โทรครับ — ในยุคก่อนปี 2010 ย้ายค่ายโทรศัพท์ต้องเปลี่ยนเบอร์. แต่หลัง MNP (Mobile Number Portability) — ย้ายค่ายแต่เก็บเบอร์ได้. Data portability คือแนวคิดเดียวกัน — แค่กับข้อมูลใน social network / email / cloud storage / streaming history

Cluster 3 — “ของฉัน — ฉันคัดค้าน / ขอให้คนรีวิว”#

ฉาก — ลูกค้าโทรมาบอก “ผมไม่อยากให้ใช้ข้อมูลผมทำ marketing — และถ้าระบบ AI จะตัดสินใจอะไรที่กระทบผม ผมอยากให้คนรีวิว”. 2 สิทธิ์ในกลุ่มนี้เกี่ยวกับ การใช้ข้อมูลในงาน marketing + AI decision

สิทธิ์ที่ 6 — Right to Object (สิทธิ์ในการคัดค้าน)#

ชาวเมืองมีสิทธิ์ คัดค้าน การประมวลผลข้อมูลของตัวเอง — โดยเฉพาะกรณี marketing / profiling. บริษัทต้องหยุดทันที เว้นแต่ บริษัทจะพิสูจน์ได้ว่ามี legitimate interest ที่ overriding (สำคัญกว่าสิทธิ์ของเจ้าของข้อมูล)

• GDPR: Article 21
• PDPA: มาตรา 32

สิทธิ์ที่ 7 — Right relating to Automated Decision-Making / Profiling#

ในยุค AI — ถ้าบริษัทใช้ระบบอัตโนมัติ (ไม่มีคนรีวิว) ตัดสินใจในเรื่องที่กระทบเจ้าของข้อมูลอย่างมีนัยสำคัญ (เช่น อนุมัติสินเชื่อ / จัดเรท insurance / กรอง candidate รับสมัครงาน) — เจ้าของข้อมูลมีสิทธิ์:

• ไม่ตกอยู่ใต้ การตัดสินใจอัตโนมัติแบบนั้น

• ขอให้คนรีวิว (human-in-the-loop)

• ขอคำอธิบาย ว่าตัดสินใจอย่างไร

• GDPR: Article 22

• PDPA: มาตรา 32 + แนวประกาศของ PDPC

สิทธิ์นี้จะใหญ่ขึ้นมากในยุค AI ปี 2026+ — เพราะ EU AI Act (บังคับใช้ 2026 บางส่วน) ผูกเข้ากับ GDPR ตรงนี้

สิทธิ์ที่ 8 — Right to Withdraw Consent (สิทธิ์ในการถอนความยินยอม)#

ถ้าฐานทางกฎหมายของการประมวลผลคือ consent — เจ้าของข้อมูลถอนได้ทุกเมื่อ ง่ายเท่ากับตอนที่ให้. ถอนแล้ว — บริษัทต้องหยุดประมวลผลในส่วนที่อิง consent นั้น

• GDPR: Article 7(3)
• PDPA: มาตรา 19 วรรค 5

หลักการนี้บังคับว่า — ถ้าตอนสมัครคุณให้ลูกค้า tick checkbox เดียวก็เข้าระบบ marketing ได้ — ตอนถอนต้อง 1 click เหมือนกัน. ห้ามให้กรอกฟอร์ม 10 หน้า / ห้ามต้องโทร call center / ห้าม “ต้องเขียนจดหมายมาที่สำนักงานใหญ่”

มุมผู้บริหาร — สิทธิ์ทั้ง 8 ต้องมี process ที่ทำได้จริง: ถ้าบริษัทคุณไม่มี data subject request (DSR) process ที่ทำได้จริงในกรอบเวลาที่กฎหมายกำหนด — คุณกำลังเดินไปสู่ค่าปรับเพียงเพราะตอบช้า. ลงทุนใน DSR portal + workflow + SLA tracker — ราคาน้อยกว่าค่าปรับและภาพลักษณ์ที่เสียมาก

ฐานที่ 1 — Consent (ความยินยอม)#

เจ้าของข้อมูล ยินยอม ให้ประมวลผล. แต่ consent ต้องครบเงื่อนไข 4 ข้อ:

• Freely given (ให้โดยอิสระ) — ห้ามบังคับ ห้ามผูกกับการให้บริการที่ไม่เกี่ยวกัน
• Specific (เฉพาะเจาะจง) — ระบุชัดว่ายินยอมเรื่องอะไร ห้ามรวม
• Informed (มีข้อมูลครบ) — เจ้าของข้อมูลต้องรู้ว่ายินยอมแล้วจะเกิดอะไร
• Unambiguous (ชัดเจน ไม่กำกวม) — opt-in ที่ active เช่น tick box. ห้าม pre-tick. ห้ามตีความจาก silence

ผิดบ่อย — bundled consent (ใน 1 checkbox มีหลายเรื่องรวมกัน) / pre-ticked checkbox / forced consent (ไม่ tick = ใช้บริการไม่ได้ ทั้งที่ไม่เกี่ยว)

ฐานที่ 2 — Contract (สัญญา)#

ประมวลผลข้อมูลเพราะ จำเป็นต่อการทำตามสัญญา กับเจ้าของข้อมูล. เช่น คุณซื้อของออนไลน์ — บริษัทต้องเก็บที่อยู่จัดส่ง เป็นไปตามฐาน contract ไม่ต้องขอ consent

ข้อจำกัด — ฐาน contract ครอบเฉพาะข้อมูลที่ จำเป็นจริงๆ ต่อสัญญา. การส่ง marketing email หลังขายของ ไม่ใช่ contract — เป็นเรื่องใหม่ที่ต้องมีฐานใหม่ (เช่น consent / legitimate interest)

ฐานที่ 3 — Legal Obligation (หน้าที่ตามกฎหมาย)#

ประมวลผลเพราะ กฎหมายอื่นบังคับ. เช่น สรรพากรบังคับให้แบงก์เก็บข้อมูลธุรกรรม / KYC ตามกฎหมาย AML / labor law บังคับให้บริษัทเก็บข้อมูลพนักงาน

ฐานที่ 4 — Vital Interest (ประโยชน์อันสำคัญยิ่งต่อชีวิต)#

ประมวลผลเพื่อ ปกป้องชีวิต ของเจ้าของข้อมูลหรือคนอื่น. เช่น โรงพยาบาลใช้ข้อมูลทางการแพทย์ของคนไข้หมดสติเพื่อรักษา. ฐานนี้แคบมาก — ใช้ใน emergency จริงๆ เท่านั้น

ฐานที่ 5 — Public Task (ภารกิจสาธารณะ)#

ประมวลผลเพื่อ ภารกิจสาธารณะ หรือ อำนาจของรัฐ. เช่น หน่วยงานราชการประมวลผลข้อมูลประชาชนเพื่อให้บริการสาธารณะ. ฐานนี้ส่วนใหญ่ใช้กับ public sector

ฐานที่ 6 — Legitimate Interest (ประโยชน์อันชอบธรรม) — ฐานที่อันตรายที่สุด#

นี่คือฐานที่ flexible ที่สุด แต่ ใช้ง่ายผิดที่สุด — ผมอยากให้คุณตั้งใจอ่านส่วนนี้เป็นพิเศษครับ เพราะนี่คือ landmine ของบริษัทไทยจำนวนมาก

ลองนึกฉาก — ร้านอาหารไทยรายหนึ่งในกรุงเทพ. มี loyalty app + ลูกค้า 50,000 ราย. ทีม marketing บอกผู้บริหาร — “อย่าขอ consent เลย ใช้ legitimate interest ก็พอ — เราจะส่ง direct marketing SMS โปรโมชั่น mango sticky rice ทุกอาทิตย์”. ผู้บริหารเซ็นอนุมัติ. 6 เดือนผ่านไป — ลูกค้า 1 รายฟ้อง PDPC. PDPC ตรวจ — เคสนี้ direct marketing ต้อง consent เท่านั้น — legitimate interest ใช้แทนไม่ได้. ผลคือ — บริษัทต้อง ลบข้อมูล marketing ทั้ง 50,000 ราย ที่เคยเก็บมา + ค่าปรับตามมาตรา 82 ของ PDPA + ภาพลักษณ์ของร้านเสียระยะยาว. ฐาน legitimate interest กลายเป็น landmine เพราะใช้ผิด

หลักการ — บริษัทประมวลผลเพราะมี ประโยชน์อันชอบธรรม + ประโยชน์นั้น ไม่ overridden โดยสิทธิ์และเสรีภาพของเจ้าของข้อมูล

ตัวอย่างที่ valid:

• บริษัทใช้ข้อมูลพนักงานเพื่อรักษาความปลอดภัยภายในองค์กร
• บริษัททำ fraud detection บน transaction
• B2B marketing ที่ส่งข้อมูลเชิง professional ให้ business contact ที่มีอยู่แล้ว

ตัวอย่างที่ไม่ valid (ที่บริษัทไทยใช้ผิดบ่อย):

• ร้านอาหาร / e-commerce อ้าง legitimate interest ส่ง direct marketing SMS / email — ผิด ต้อง consent
• ใช้ทำ profiling สำหรับ targeted ads โดยไม่ขอ consent — ผิด
• เก็บข้อมูลลูกค้าทุกอย่างที่อยากเก็บ “เผื่อใช้” — ผิด ขัด data minimisation

ฐาน legitimate interest ต้องทำ LIA (Legitimate Interest Assessment) เป็นเอกสาร — ระบุว่า (1) interest คืออะไร (2) จำเป็นไหม (3) balance ดีไหม. ไม่มี LIA = ใช้ฐานนี้ไม่ได้

มุมผู้บริหาร — ฐาน legitimate interest ห้ามใช้แทน consent: หลายบริษัทไทยอาจคิดว่า “อ้าง legitimate interest แทน consent ก็ได้” — เพราะไม่ต้องขอ checkbox. ผิดและอันตรายมาก. การประมวลผลที่ปกติต้อง consent (เช่น direct marketing / cookies tracking / profiling) ใช้ legitimate interest ไม่ได้. ใช้ผิด = ผิด GDPR/PDPA ทั้งกระบวนการ — ต้องลบข้อมูลที่เก็บมา + ค่าปรับ

ข้อมูล Sensitive — 6 ฐาน “ไม่พอ”#

มี ข้อมูลพิเศษ (Special Categories / Sensitive Data) — ที่กฎหมายคุ้มครองเข้มกว่าปกติ ได้แก่:

• เชื้อชาติ / ชาติพันธุ์
• ความคิดเห็นทางการเมือง
• ความเชื่อทางศาสนา
• สมาชิกสหภาพแรงงาน
• ข้อมูลพันธุกรรม / biometric
• ข้อมูลสุขภาพ
• ข้อมูลทางเพศ / รสนิยมทางเพศ
• PDPA เพิ่ม: ประวัติอาชญากรรม

สำหรับข้อมูลกลุ่มนี้ — ฐาน 6 ข้อข้างต้น ไม่พอ ต้องมีฐานพิเศษเพิ่ม (Article 9 GDPR / มาตรา 26 PDPA) — เช่น explicit consent / vital interest / public health / employment law

กลไกที่ 1 — Adequacy Decision (การตัดสินใจรับรองความเพียงพอ)#

EU Commission ประกาศว่า ประเทศ X มีกฎหมายคุ้มครองข้อมูลในระดับเทียบเท่า EU — บริษัทใน EU ส่งข้อมูลไปประเทศนั้นได้เลย ไม่ต้องทำอะไรเพิ่ม

ประเทศที่มี adequacy ณ ต้นปี 2026 — ประมาณ 15 ประเทศ เช่น UK, สวิตเซอร์แลนด์, แคนาดา (commercial), ญี่ปุ่น, เกาหลีใต้, อิสราเอล, อาร์เจนตินา, นิวซีแลนด์, อังกฤษ, อุรุกวัย, เซอร์เบีย, ฯลฯ

ไทย — ยังไม่ได้ adequacy. PDPC กำลังพัฒนา framework เพื่อขออยู่ — แต่ ณ ต้นปี 2026 ยังไม่ผ่าน. แปลว่า ถ้าบริษัท EU ส่งข้อมูลมาไทย — ต้องใช้กลไกอื่น

US — ผ่านมาแล้ว 3 รอบ ล้มไป 2 รอบ:

• Safe Harbor (2000-2015) — ล้มโดย CJEU ในเคส Schrems I
• Privacy Shield (2016-2020) — ล้มโดย CJEU ในเคส Schrems II
• EU-US Data Privacy Framework (2023-ปัจจุบัน) — รอบที่ 3 ผ่านในปี 2023 แต่ยัง อยู่ภายใต้ challenge ในศาล EU

เคส Schrems II 2020 — คำพิพากษาที่เปลี่ยนเกม cloud ทั้งหมด#

Max Schrems นักรณรงค์ privacy ชาวออสเตรีย ฟ้องเรื่อง Facebook ส่งข้อมูลตัวเขาไป US. CJEU (Court of Justice of the European Union) วินิจฉัย 16 กรกฎาคม 2020:

1. Privacy Shield ใช้ไม่ได้ — เพราะกฎหมาย surveillance ของ US (เช่น FISA Section 702) ให้อำนาจ NSA ดูข้อมูลที่อยู่ใน server US โดยไม่มี judicial oversight ที่เพียงพอ สำหรับชาว non-US
2. SCC (Standard Contractual Clauses) ใช้ได้ต่อ — แต่ต้องทำ Transfer Impact Assessment (TIA) + อาจต้องเพิ่ม supplementary measures เช่น encryption-at-rest ที่ key อยู่ใน EU เพื่อให้ US authority access ไม่ได้

ผลกระทบ — บริษัททั่วโลกที่ใช้ AWS US / Azure US / Google Cloud US ต้องทำ TIA + supplementary measures ทุกราย. เกิดการ shift ครั้งใหญ่ไปใช้ EU regions ของ cloud provider

3 ปีหลัง Schrems II — Meta โดน DPC ปรับ €1.2 พันล้าน (พฤษภาคม 2023) — เพราะหลัง Privacy Shield ล้ม Meta ยังคง transfer ข้อมูลไป US ด้วย SCC ที่ supplementary measures ไม่เพียงพอ

กลไกที่ 2 — SCC (Standard Contractual Clauses) — สัญญามาตรฐาน#

SCC = Standard Contractual Clauses (สัญญามาตรฐาน) — EU Commission ออก template สัญญาสำเร็จรูป. บริษัทที่ส่งข้อมูลข้าม border ใช้ template นี้ ผูกฝ่ายปลายทาง ให้คุ้มครองข้อมูลในระดับ EU

หลัง Schrems II — SCC ใหม่ออกปี 2021 (module-based) + ต้องทำ TIA ก่อนใช้

SCC คือกลไกที่บริษัทไทยส่วนใหญ่จะใช้กับลูกค้า/vendor ใน EU — เพราะไทยยังไม่มี adequacy

กลไกที่ 3 — BCR (Binding Corporate Rules) — กฎภายในข้ามชาติ#

BCR = Binding Corporate Rules (กฎภายในข้ามชาติที่มีผลผูกพัน) — บริษัทข้ามชาติเขียน internal policy ที่บังคับใช้กับทุก subsidiary ทั่วโลก + ส่งให้ supervisory authority ของ EU อนุมัติ. อนุมัติเสร็จ ใช้ภายในกลุ่มบริษัทได้

BCR เหมาะกับบริษัทใหญ่ที่มี subsidiary หลายประเทศ — เช่น Siemens, Schneider Electric, IBM. ใช้เวลา 1-2 ปีในการขออนุมัติ — ลงทุนหนัก แต่ flexible ที่สุดสำหรับ intra-group transfer

Data Sovereignty + Data Localization — แนวคิดที่กำลังเติบโต#

Data Sovereignty (อธิปไตยทางข้อมูล) = แนวคิดที่ว่า ข้อมูลในประเทศต้องอยู่ภายใต้กฎหมายของประเทศนั้น. ขยายเป็นกฎหมาย:

• Data Localization (การกักข้อมูลในประเทศ) = กฎหมายบังคับให้ข้อมูลของพลเมือง ต้องเก็บใน server ภายในประเทศ

ตัวอย่าง:

• จีน (PIPL — Personal Information Protection Law 2021) บังคับ critical data + bulk personal info ต้อง localize
• รัสเซีย บังคับ data ของพลเมืองรัสเซีย primary copy ต้องอยู่ในรัสเซีย
• อินเดีย (DPDP Act 2023) — flexible แต่มี restriction บางหมวด
• เวียดนาม (Cybersecurity Law 2018) — บังคับ local storage บางหมวด
• ไทย — PDPA ไม่ได้ บังคับ localization โดยตรง — แต่บางหมวด (เช่น ข้อมูลสุขภาพ / financial) มีกฎเฉพาะ
• EU — ไม่บังคับ localization โดยตรง แต่ Schrems II สร้างผลคล้ายๆ กัน — บริษัทเริ่มเลือก EU region แทน US เพราะง่ายกว่า

ผลกระทบต่อบริษัทไทย — ถ้ามีลูกค้าจีน / รัสเซีย / เวียดนาม ห้าม assume ว่า cloud region เดิม (เช่น Singapore) ครอบทุกประเทศ. ต้องตรวจ data localization requirement ของแต่ละประเทศ — บางครั้งต้องตั้ง region ใหม่หรือใช้ local cloud provider

มุมผู้บริหาร — cloud region ไม่ใช่เรื่อง technical อย่างเดียว — เป็นเรื่อง legal: การเลือก AWS region / Azure region — เคยเป็นเรื่อง latency + cost. หลัง Schrems II + data localization laws — เป็นเรื่อง legal compliance + business risk. ต้องให้ DPO + legal คุย กับ infrastructure team ก่อนตัดสินใจ ไม่ใช่หลัง

DPO (Data Protection Officer) — เจ้าหน้าที่คุ้มครองข้อมูล#

DPO = Data Protection Officer (เจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล) — ตำแหน่งที่กฎหมายกำหนดบทบาทและความเป็นอิสระไว้ชัด

หน้าที่ของ DPO:

1. ให้คำปรึกษา ผู้บริหารและพนักงานเรื่อง compliance
2. monitor compliance ภายในองค์กร
3. เป็น contact point ของเจ้าของข้อมูล + supervisory authority
4. ทำ DPIA (จะคุยต่อ)
5. train พนักงานเรื่อง privacy

หลักการสำคัญ — DPO ต้องเป็นอิสระ (independence):

• รายงานต่อ ระดับสูงสุดของบริษัท (board หรือ CEO)
• ห้ามมี conflict of interest (เช่น เป็น CIO + DPO ในคนเดียวกัน — ไม่ได้ เพราะ CIO คือคนที่ออกแบบระบบที่ DPO ต้อง audit)
• ห้ามถูก fire เพียงเพราะทำตามหน้าที่ DPO

ใครต้องมี DPO:

• GDPR Article 37 — บริษัทที่ (1) เป็น public authority (2) ประมวลผล large scale ที่ต้อง monitor regular + systematic (3) ประมวลผล sensitive data large scale
• PDPA มาตรา 41 — บริษัทที่ (1) เป็น public authority (2) processing activities ต้อง monitor large scale + regular + systematic (3) ใช้ข้อมูลพิเศษ large scale

ในทางปฏิบัติ — บริษัทขนาดกลาง-ใหญ่ในไทยที่ทำธุรกิจกับลูกค้าจำนวนมาก (e-commerce / fintech / health / education / telecom) — มี DPO เกือบหมด แม้กฎไม่บังคับชัดเจน เพราะ defensibility ดีกว่ามาก

DPIA (Data Protection Impact Assessment) — การประเมินผลกระทบ#

DPIA = Data Protection Impact Assessment (การประเมินผลกระทบด้านการคุ้มครองข้อมูล) — กระบวนการประเมิน ก่อน เริ่มประมวลผลที่ เสี่ยงสูง ต่อสิทธิ์ของเจ้าของข้อมูล

เมื่อไหร่ที่ต้องทำ DPIA:

• ใช้ เทคโนโลยีใหม่ (AI / biometric / large-scale monitoring)
• systematic monitoring พื้นที่สาธารณะ (CCTV ขนาดใหญ่)
• ประมวลผล sensitive data large scale
• ทำ automated decision-making ที่กระทบเจ้าของข้อมูลอย่างมีนัยสำคัญ

DPIA มี 4 ขั้นตอนหลัก:

1. อธิบาย กระบวนการประมวลผล (อะไร ทำไม ยังไง นานเท่าไหร่)
2. ประเมินความจำเป็นและสัดส่วน — ทำน้อยกว่านี้ได้ไหม
3. identify ความเสี่ยง ต่อเจ้าของข้อมูล
4. ระบุ measures ในการ mitigate

ถ้า DPIA ระบุว่ามี high risk ที่ mitigate ไม่ได้ — ต้อง prior consultation กับ supervisory authority (Article 36 / มาตรา 40) ก่อนเริ่ม

DPIA ไม่ใช่เอกสาร one-shot — เป็น living document ที่ update เมื่อ process เปลี่ยน

Privacy by Design + by Default#

Privacy by Design (การออกแบบโดยคำนึงถึงความเป็นส่วนตัว) = แนวคิดที่ Ann Cavoukian (อดีต Privacy Commissioner ของ Ontario) เสนอตั้งแต่ 1990s — และ GDPR Article 25 บรรจุเป็นกฎหมายในปี 2018

หลักการ:

• Privacy ต้อง built-in ตั้งแต่ design phase ไม่ใช่ bolt-on ตอนจะ launch
• Default setting ต้องเป็น privacy-friendly — ผู้ใช้ไม่ต้อง opt-out เพื่อปกป้องตัวเอง
• End-to-end coverage — ครอบทั้ง lifecycle ของข้อมูล

ตัวอย่างที่ผิด — ระบบใหม่ที่ “เก็บข้อมูลให้ครบก่อน เดี๋ยวค่อยกรอง” / privacy setting ที่ default = สาธารณะ ตัวอย่างที่ถูก — ระบบที่ default = visible เฉพาะตัวเอง / มี data retention auto-delete / มี encryption ในชั้น storage + transit by default

มุมผู้บริหาร — ลงทุนใน 3 ขา (DPO + DPIA + Privacy by Design) = ลงทุนใน defensibility: เคสที่บริษัทโดนปรับใหญ่หลายเคส — ไม่ใช่เพราะระบบโดน hack อย่างเดียว — แต่เพราะ ไม่มีเอกสารพิสูจน์ว่าทำตามขั้นตอน. มี DPO + ทำ DPIA + ออกแบบ system แบบ privacy-by-design — เมื่อโดน audit คุณมีของพิสูจน์. ไม่มี = default ผิด

2 leader takeaways ก่อนเข้าบ้าน#

Takeaway 1 — Privacy ไม่ใช่เรื่องของ IT — เป็นเรื่องของ board. ค่าปรับ 4% รายได้ทั่วโลกของ GDPR / 5 ล้านบาทต่อกรณีของ PDPA / โทษอาญาที่ติดคุกได้ — ไม่ใช่เรื่องที่ delegate ลงทีม IT ได้. ต้องมีคนที่ระดับ C-suite + board เข้าใจ + ตัดสินใจ. DPO ต้องรายงานสูงสุดของบริษัท

Takeaway 2 — Documentation = Defensibility. ในเคสที่บริษัทถูกปรับใหญ่ — เหตุผลส่วนใหญ่ไม่ใช่ “โดน hack” — แต่เป็น “พิสูจน์ไม่ได้ ว่าทำตามขั้นตอน”. มี data inventory / consent log / DPIA / DPA / privacy notice / DSR process — เมื่อเจอ audit คุณมีของ. ไม่มี = default ผิดตามหลัก accountability