สรุปเนื้อหาการสัมมนา: PDPA Guru - รู้ชัด ปฏิบัติชัวร์ - ในฐานะผู้ประมวลผลข้อมูลส่วนบุคคล (Data Processor)

ข้อมูลทั่วไป

• วันที่และเวลา: วันอังคารที่ 19 สิงหาคม 2568 เวลา 10.00 น.

• วิทยากร:

  • ดร. อุดมธิปก ไพรเกษตร

  • อาจารย์สุกฤษ โกยอัครเดช

  • อาจารย์ปภัสรา อังค์ยศ

• รูปแบบ: (Webinar) ทำความเข้าใจและการถอดบทเรียนเกี่ยวกับผู้ประมวลผลข้อมูลส่วนบุคคล (Data Processor)

บทนำ

การสัมมนาในหัวข้อ "PDPA Guru - รู้ชัด ปฏิบัติชัวร์ - ในฐานะผู้ประมวลผลข้อมูลส่วนบุคคล (Data Processor)" จัดขึ้นเพื่อให้ผู้ที่เกี่ยวข้องกับการประมวลผลข้อมูลส่วนบุคคลในฐานะผู้ประมวลผลข้อมูล (Data Processor) มีความเข้าใจที่ถูกต้องเกี่ยวกับบทบาท หน้าที่ ความรับผิดชอบ และแนวทางการปฏิบัติตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA)

การสัมมนานี้มุ่งเน้นไปที่การทำความเข้าใจความแตกต่างระหว่างผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) และผู้ประมวลผลข้อมูลส่วนบุคคล (Data Processor) รวมถึงสถานการณ์ที่ต้องมีการจัดทำข้อตกลงการประมวลผลข้อมูลส่วนบุคคล (Data Processing Agreement - DPA) และข้อตกลงการแบ่งปันข้อมูล (Data Sharing Agreement - DSA) นอกจากนี้ยังครอบคลุมประเด็นสำคัญเกี่ยวกับการโอนข้อมูลส่วนบุคคลไปต่างประเทศ มาตรการคุ้มครองข้อมูลส่วนบุคคลในมิติต่างๆ และความรับผิดชอบในกรณีที่ข้อมูลรั่วไหล

ความแตกต่างระหว่างผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) และผู้ประมวลผลข้อมูลส่วนบุคคล (Data Processor)

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

ผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) คือบุคคลหรือนิติบุคคลที่มีอำนาจตัดสินใจเกี่ยวกับการเก็บรวบรวม ใช้ หรือเปิดเผยข้อมูลส่วนบุคคล โดยเป็นผู้กำหนดวัตถุประสงค์และวิธีการในการประมวลผลข้อมูล ตัวอย่างที่ยกมาในการสัมมนาคือ โรงพยาบาลที่ทำการรักษาพยาบาลและบริษัทประกันที่รับเบิกประกัน ในกรณีนี้ โรงพยาบาลและบริษัทประกันต่างเป็น Data Controller ซึ่งทำธุรกิจร่วมกันและมีการแชร์ข้อมูลระหว่างกันในฐานะ Data Controller ด้วยกันเอง

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

นิยามและเกณฑ์การพิจารณาว่าเป็น Data Processor

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

• ไม่จำกัดเฉพาะบริษัทจำกัด สามารถเป็นบุคคลธรรมดา ห้างหุ้นส่วนสามัญ ห้างหุ้นส่วนจำกัด หรือบริษัทมหาชนจำกัดได้

• สถานะเกิดโดยผลทางกฎหมาย (โดยสภาพ) หากเข้าสู่นิยาม ไม่จำเป็นต้องมีการแต่งตั้งอย่างเป็นทางการหรือสัญญา หากทำตามคำสั่งของ Data Controller ในกิจกรรมที่มีข้อมูลส่วนบุคคล ก็ถือเป็น Data Processor โดยอัตโนมัติ

• ตัวอย่าง:

  • ธนาคารใช้บริการ Cloud เพื่อเก็บข้อมูลลูกค้าและพัฒนาแอปพลิเคชัน บริษัท Cloud ถือเป็น Data Processor

  • บริษัทจัดนิทรรศการจ้างบริษัท Marketing Research รวบรวมข้อมูลผู้เข้าร่วม โดยไม่ได้กำหนดวัตถุประสงค์เอง บริษัทวิจัยถือเป็น Data Processor

• พนักงานภายในองค์กรเดียวกันไม่ถือเป็น Data Processor ตามกฎหมาย แม้จะประมวลผลข้อมูล เพราะถือเป็นส่วนหนึ่งของนิติบุคคลเดียวกัน

หน้าที่ตามกฎหมายของ Data Processor

• กำหนดไว้ในมาตรา 40 ของ PDPA พ.ศ. 2562: ทำตามคำสั่งของ Data Controller, ห้ามใช้ข้อมูลส่วนบุคคลเพื่อประโยชน์ส่วนตัว, มีมาตรการรักษาความปลอดภัยข้อมูล, บันทึกกิจกรรมการประมวลผล (RoPA), และแจ้งการละเมิดข้อมูล (Data Breach) หากเกิดขึ้น

• ต้องมีมาตรการรักษาความปลอดภัยเท่ากันหรือสูงกว่า Data Controller โดยเฉพาะในสัญญาว่าจ้าง ซึ่งอาจไม่ลงรายละเอียดเฉพาะข้อมูลส่วนบุคคล แต่ต้องครอบคลุม

• ตัวอย่างกิจกรรม:

  • รับจ้างทำระบบ Human Resource ซึ่งเกี่ยวข้องกับข้อมูลพนักงาน ถือเป็นผลพลอยได้จากการว่าจ้าง แต่ต้องมีมาตรการรักษาความปลอดภัย

• หากเกิด Data Breach: แจ้ง Data Controller ที่เกี่ยวข้อง และอาจแจ้งสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) หากกระทบหลายราย เช่น ในระบบ Cloud ที่มีลูกค้าหลายองค์กร

• การลบทำลายข้อมูล: ต้องทำเมื่อหมดวัตถุประสงค์ โดยบันทึกใน RoPA และสัญญา DPA

การแต่งตั้ง DPO สำหรับ Data Processor

• เงื่อนไขเหมือน Data Controller ตามมาตรา 41 (2):

  1. เป็นหน่วยงานรัฐตามที่คณะกรรมการประกาศ (ปัจจุบัน 85 หน่วยงาน รวมองค์กรปกครองส่วนท้องถิ่น)

  2. มีการเก็บรวบรวมข้อมูลส่วนบุคคลที่ต้องเฝ้าระวังและตรวจสอบอย่างเป็นระบบ และจำนวนมาก (เช่น เกิน 100,000 ราย)

• ตัวอย่าง: บริษัทรับจ้างทำ Payroll ที่ตรวจสอบและคำนวณเงินเดือน หากเห็นข้อมูลจำนวนมาก ถือว่าต้องแต่งตั้ง DPO

• หน้าที่ DPO ของ Data Processor เหมือน Data Controller: ให้คำปรึกษา, ตรวจสอบติดตาม, ประสานงานกับสคส. และ Data Subject, รักษาความลับ, และรายงานตรงถึงบอร์ดผู้บริหาร (High Autonomy)

• หากองค์กรเป็นทั้ง Data Controller และ Data Processor สามารถใช้ DPO คนเดียวกันได้ หากไม่มี Conflict of Interest

• DPO ต้องมีความเป็นอิสระสูง สามารถตรวจสอบและรายงานโดยไม่ผ่าน CEO หรือ MD หากเกิดปัญหา

การบันทึกกิจกรรมการประมวลผล (RoPA)

• ความแตกต่างจาก Data Controller ไม่มาก บันทึกกิจกรรมไม่ใช่บันทึกข้อมูลลูกค้าแต่ละราย แต่บันทึกกระบวนการทั้งหมด ตั้งแต่รับข้อมูลจนลบทำลาย

• สำหรับ Data Processor: เริ่มจาก Data Subject หรือ Controller ส่งข้อมูลมา, ประมวลผลภายในองค์กร (ผ่านหน่วยงานไหน, ระบบอัตโนมัติอย่างไร), ส่งคืน, และลบทำลาย

• ตัวอย่าง:

  • Front-end Processor (เช่น รับจ้างวิจัย): บันทึกตั้งแต่เก็บจาก Data Subject จนส่งให้ Controller และลบ

  • Back-end Processor (เช่น Software as a Service): บันทึกการรับข้อมูล, ประมวลผลอัตโนมัติ, การอัปเดตระบบ, การแก้ปัญหา, และการลบเมื่อเลิกใช้

• ต้องรวมกิจกรรมภายใน เช่น การยืนยันตัวตน Data Subject หากระบบเปิดให้เข้าถึงโดยตรง

• สคส. มีประกาศยกเว้น RoPA สำหรับองค์กรขนาดเล็ก แต่ Data Processor ต้องทำหากเข้าเงื่อนไข

ถอดบทเรียนจาก 3 กรณีศึกษาการลงโทษปรับ

การบังคับใช้กฎหมายล่าสุดได้แสดงให้เห็นว่า DP ต้องรับผิดชอบไม่ต่างจาก DC ดังนี้

สถานการณ์ที่ต้องใช้ Data Processing Agreement (DPA) และ Data Sharing Agreement (DSA) พร้อมตัวอย่าง

การเลือกใช้ข้อตกลงที่เหมาะสมระหว่าง Data Processing Agreement (DPA) และ Data Sharing Agreement (DSA) เป็นสิ่งสำคัญในการปฏิบัติตาม PDPA โดยการสัมมนาได้ให้แนวทางและตัวอย่างที่ชัดเจนเพื่อช่วยในการตัดสินใจ

Data Processing Agreement (DPA)

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

• การทำลายเอกสาร: การส่งข้อมูลไปให้บริษัทภายนอกเพื่อทำลายเอกสารหรือข้อมูลส่วนบุคคล ถือเป็นการประมวลผลข้อมูลตามคำสั่งของ Data Controller ซึ่งบริษัทรับทำลายเอกสารมีสถานะเป็น Data Processor

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

  • ตัวอย่างเช่น บริษัท A ว่าจ้างบริษัท B เพื่อทำ Mobile Application สำหรับเก็บรวบรวมข้อมูลของ Data Subject (กลุ่มใหม่) และยังส่งข้อมูล Data Subject (กลุ่มเก่า) ให้บริษัท B เพื่อวิเคราะห์ต่อในแอปพลิเคชันเดียวกัน ในกรณีนี้ บริษัท B มีสถานะเป็น Data Processor และควรทำ DPA กับบริษัท A เนื่องจากเป็นการประมวลผลข้อมูลเพื่อพัฒนาการให้บริการแอปพลิเคชัน ซึ่งถือเป็นกิจกรรมเดียวกัน

ประเด็นสำคัญที่ถูกเน้นย้ำคือ Data Processor จะต้องปฏิบัติตามคำสั่งของ Data Controller ในทุกขั้นตอน หาก Data Processor ไม่ยอมลงนามใน DPA หรือเกิดความเสียหายต่อ Data Subject จากความบกพร่องของ Data Processor เอง Data Controller สามารถเรียกค่าเสียหายตามกฎหมายได้ แม้ว่ากฎหมาย PDPA จะไม่ได้ระบุบทลงโทษโดยตรงหาก Data Processor ไม่ยอมเซ็น DPA แต่ในทางปฏิบัติ Data Controller ควรเก็บหลักฐานการพยายามส่ง DPA ให้ Data Processor ลงนาม เพื่อใช้เป็นหลักฐานในกรณีเกิดเหตุการณ์ไม่พึงประสงค์

Data Sharing Agreement (DSA)

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

• โรงพยาบาลและบริษัทประกัน: ดังที่กล่าวไปในส่วนที่ 1 โรงพยาบาลและบริษัทประกันต่างเป็น Data Controller การแชร์ข้อมูลเพื่อการรักษาพยาบาลและการเบิกประกันจึงควรทำ DSA

• บริษัทที่ทำประกันให้พนักงาน: หากบริษัทต้องการทำประกันอุบัติเหตุให้กับพนักงานและมีการส่งข้อมูลส่วนบุคคลของพนักงานไปยังบริษัทประกัน บริษัทประกันไม่ใช่ Data Processor ของบริษัทนั้น เนื่องจากบริษัทประกันมีหน้าที่และอยู่ภายใต้การกำกับดูแลของ คปภ. การโอนข้อมูลระหว่างกันจึงควรทำ DSA

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

สรุปหลักการพิจารณา

การสัมมนาได้ให้หลักการสำคัญในการพิจารณาว่าควรใช้ DPA หรือ DSA โดยพิจารณาจาก:

1. ความเป็นนิติบุคคล: หากเป็นคนละนิติบุคคลกัน แปลว่ามี Data Controller อื่นเข้ามาเกี่ยวข้อง

2. สถานะของผู้รับจ้าง: ผู้รับจ้างเป็นบุคลากรในองค์กรหรือไม่ หากเป็นบุคลากรในองค์กรที่ทำงานตามหน้าที่หลัก ไม่จำเป็นต้องทำ DPA แต่หากเป็นบุคลากรที่ทำงานนอกเวลาหรือกิจกรรมที่ไม่ใช่หน้าที่หลัก (เช่น พนักงานโรงพยาบาลรับจ้างส่งยาที่บ้านนอกเหนือเวลางาน) อาจต้องพิจารณาความสัมพันธ์ในฐานะ Data Processor

3. วัตถุประสงค์และอำนาจในการประมวลผล: หากผู้รับข้อมูลมีอำนาจในการกำหนดวัตถุประสงค์และวิธีการประมวลผลข้อมูลด้วยตนเอง (แม้จะทำธุรกิจร่วมกัน) ก็ควรทำ DSA แต่หากทำตามคำสั่งของผู้ให้ข้อมูลอย่างเคร่งครัด ก็ควรทำ DPA

การโอนข้อมูลส่วนบุคคลไปต่างประเทศ (Cross-Border Data Transfer)

ประเด็นเรื่องการโอนข้อมูลส่วนบุคคลไปต่างประเทศเป็นอีกหนึ่งหัวข้อสำคัญที่ถูกหยิบยกมาหารือในการสัมมนา โดยเฉพาะอย่างยิ่งในยุคที่การใช้บริการคลาวด์จากผู้ให้บริการต่างประเทศเป็นเรื่องปกติ คำถามที่น่าสนใจคือ หากข้อมูลส่วนบุคคลอยู่บนคลาวด์ต่างประเทศ จะต้องพิจารณาเรื่อง Cross-Border Transfer อย่างไร

การสัมมนาได้อธิบายว่า การโอนข้อมูลไปต่างประเทศตามมาตรา 28-29 ของกฎหมายไทยนั้น อาจไม่ได้อธิบายรายละเอียดอย่างชัดเจนว่าวิธีการโอนแบบใดถึงจะเข้าข่ายคำว่า 'โอนไปต่างประเทศ' อย่างไรก็ตาม ได้มีการให้หลักการพิจารณาเบื้องต้นว่า การโอนข้อมูลไปต่างประเทศจะเกิดขึ้นเมื่อมีองค์ประกอบ 3 ประการ ได้แก่:

1. โอนโดยบุคคลที่อยู่ภายใต้การกำกับ PDPA: หมายถึงการโอนข้อมูลโดย Data Controller หรือ Data Processor ที่อยู่ภายใต้กฎหมาย PDPA ของไทย

2. โอนไปอีก Entity หนึ่ง: ข้อมูลถูกโอนไปยังนิติบุคคลหรือหน่วยงานอื่นที่แตกต่างจากผู้โอน

3. โอนไปประเทศที่สาม: ข้อมูลถูกส่งไปยังประเทศอื่นที่ไม่ใช่ประเทศไทย

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

อย่างไรก็ตาม หากเป็นกรณีที่ธนาคารในประเทศไทยไปใช้บริการ System Integrator (SI) ที่อยู่ในเมืองไทย แต่ SI นั้นไปใช้บริการคลาวด์ที่อยู่ต่างประเทศ (เช่น อินเดีย) และเจ้าหน้าที่ในประเทศนั้นสามารถเข้าถึงข้อมูลของธนาคารได้ กรณีเช่นนี้ถือเป็นการโอนข้อมูลไปต่างประเทศ ซึ่งมีความซับซ้อนและเกี่ยวข้องกับเรื่องขององค์ประกอบเหล่านี้

มาตรการคุ้มครองข้อมูล (เชิงนโยบาย เทคนิค กายภาพ)

การสัมมนาได้เน้นย้ำถึงความสำคัญของการวางมาตรการคุ้มครองข้อมูลส่วนบุคคลในสามมิติหลัก ได้แก่ มาตรการเชิงนโยบาย (Organizational Measures) มาตรการเชิงเทคนิค (Technical Measures) และมาตรการเชิงกายภาพ (Physical Measures) เพื่อให้องค์กรสามารถปฏิบัติตาม PDPA ได้อย่างมีประสิทธิภาพและลดความเสี่ยงจากการละเมิดข้อมูล

มาตรการเชิงนโยบาย (Organizational Measures)

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

• นโยบายความเป็นส่วนตัว (Privacy Policy): การจัดทำนโยบายความเป็นส่วนตัวที่ชัดเจนว่าองค์กรจะเก็บรวบรวม ใช้ หรือเปิดเผยข้อมูลส่วนบุคคลแบบไหน อย่างไร

• คู่มือการปฏิบัติงานของพนักงาน: การนำนโยบายความเป็นส่วนตัวไปบรรจุไว้ในคู่มือการปฏิบัติงานของพนักงาน เพื่อให้พนักงานทุกคนเข้าใจและปฏิบัติตาม

• การจัดฝึกอบรมเพื่อสร้างความตระหนักรู้: การจัดอบรมให้ความรู้แก่พนักงานอย่างสม่ำเสมอ เพื่อสร้างความตระหนักและความเข้าใจเกี่ยวกับ PDPA และแนวทางการคุ้มครองข้อมูลส่วนบุคคล

มาตรการเชิงเทคนิค (Technical Measures)

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

• ความเข้มข้นของ Cyber Security: ระดับความเข้มข้นของมาตรการรักษาความปลอดภัยทางไซเบอร์ควรขึ้นอยู่กับประเภทและความอ่อนไหวของข้อมูลที่องค์กรดูแล หากเป็นข้อมูลที่มีลักษณะพิเศษ (Sensitive Data) มาตรการรักษาความปลอดภัยก็ต้องสูงตามไปด้วย

• การจัดหมวดหมู่ข้อมูล (Data Classification): การจัดหมวดหมู่ข้อมูลเป็นสิ่งสำคัญ เพื่อกำหนดสิทธิ์การเข้าถึงข้อมูลที่แตกต่างกัน พนักงานที่ไม่มีสิทธิ์ไม่ควรเข้าถึงข้อมูล หรือหากเข้าถึงได้ก็ควรเห็นข้อมูลในรูปแบบที่ไม่สามารถระบุตัวตนได้ (เช่น การเข้ารหัส)

• การควบคุมการเข้าถึง (Access Control): การกำหนดสิทธิ์การเข้าถึงข้อมูลอย่างเข้มงวด เช่น พนักงานที่เข้าถึงข้อมูลได้แต่ไม่มีสิทธิ์ลบข้อมูล หรือการกำหนดให้ต้องมีสองกุญแจ (Two-factor authentication) สำหรับการลบข้อมูลสำคัญ

มาตรการเชิงกายภาพ (Physical Measures)

มาตรการเชิงกายภาพเกี่ยวข้องกับการรักษาความปลอดภัยของสถานที่และอุปกรณ์ที่จัดเก็บข้อมูล การสัมมนาได้ยกตัวอย่างดังนี้:

• การควบคุมการเข้าถึงห้อง Server: การกำหนดว่าใครบ้างที่สามารถเข้าถึงห้อง Server ได้

• การรักษาความปลอดภัยของเอกสารและอุปกรณ์: การจัดเก็บเอกสารหรือข้อมูลในตู้ที่ปลอดภัย หรือการมีมาตรการป้องกันการเข้าถึงข้อมูลในรูปแบบกายภาพอื่นๆ

ประเด็นสำคัญที่ถูกเน้นย้ำคือ หลายหน่วยงานมักจะเข้าใจผิดว่าการทำ Data Processing Agreement (DPA) เป็นการปัดความรับผิดชอบจาก Data Controller ไปยัง Data Processor ซึ่งเป็นความเข้าใจที่คลาดเคลื่อน ความรับผิดชอบหลักยังคงอยู่กับ Data Controller เสมอ การที่ Data Processor จะรับผิดชอบได้นั้น จะต้องเป็นกรณีที่ Data Processor ไม่ปฏิบัติตามคำสั่งของ Data Controller หรือประมวลผลข้อมูลเกินกว่าที่ได้รับคำสั่ง หรือไม่ปฏิบัติตาม PDPA

ตัวอย่างที่ชัดเจนคือ บริษัทประกัน ทนายความ ผู้ตรวจสอบบัญชี หรือโรงพยาบาล มักจะไม่ใช่ผู้ประมวลผลข้อมูลส่วนบุคคลขององค์กรอื่น เนื่องจากพวกเขามีวิชาชีพของตนเองและอยู่ภายใต้การกำกับดูแลของหน่วยงานกำกับดูแลเฉพาะ (เช่น คปภ. สำหรับบริษัทประกัน) ทำให้ไม่สามารถถูกสั่งการได้ 100% ตามนิยามของ Data Processor การทำงานร่วมกันในกรณีเหล่านี้จึงมักเป็นการแชร์ข้อมูลระหว่าง Data Controller ด้วยกันเอง ซึ่งเหมาะสมกับการทำ Data Sharing Agreement (DSA) มากกว่า Data Processing Agreement (DPA)

อีกตัวอย่างหนึ่งที่น่าสนใจคือ กรณีของเจ้าหน้าที่คอมพิวเตอร์ภายในองค์กรที่ทำหน้าที่เก็บรักษาข้อมูลในระบบฐานข้อมูล เจ้าหน้าที่เหล่านี้ไม่ใช่ผู้ควบคุมข้อมูลส่วนบุคคลและไม่ใช่ผู้ประมวลผลข้อมูลส่วนบุคคล แต่เป็นเพียงผู้ที่ทำงานให้กับ Data Controller ซึ่งก็คือโรงพยาบาลหรือองค์กรนั้นๆ ผู้ควบคุมข้อมูลส่วนบุคคลมีเพียงคนเดียวคือองค์กรหรือนิติบุคคลนั้นเอง

กรณีข้อมูลรั่วไหลโดยแฮกเกอร์และความรับผิดชอบ

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

การสัมมนาได้ระบุไว้อย่างชัดเจนว่า หากองค์กรได้ดำเนินการตามกฎระเบียบและวางมาตรการคุ้มครองข้อมูลอย่างครบถ้วนแล้ว แต่ข้อมูลยังคงรั่วไหลออกไปโดยแฮกเกอร์ จะไม่ถือว่ามีความผิดตามกฎหมาย PDPA (ต้องมีมาตรการป้องกันและแผนรับมือเหตุละเมิดที่เหมาะสมด้วย) อย่างไรก็ตาม แม้จะไม่ผิด PDPA แต่อาจมีความผิดตามกฎหมายอื่นหรือข้อตกลงอื่นที่ทำไว้กับลูกค้าได้

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

โดยความแตกต่างของบทลงโทษภายใต้ PDPA ซึ่งประกอบด้วยโทษทางอาญา ทางแพ่ง และทางปกครอง กรณีที่หน่วยงานรัฐมีการแถลงข่าวการลงโทษองค์กรต่างๆ มักจะเป็นโทษทางปกครอง ซึ่งเป็นการดำเนินการระหว่างรัฐกับประชาชนหรือเอกชนเพื่อความสงบเรียบร้อยของประเทศ และค่าปรับที่ได้จะเข้าสู่รัฐ ไม่ได้ให้กับผู้เสียหายโดยตรง

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

ความสำคัญของหลัก Accountability สำหรับผู้บริหาร

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

ผู้บริหารในฐานะผู้นำองค์กรจำเป็นต้องมีสำนึกรับผิดชอบและตระหนักว่าข้อมูลส่วนบุคคลในปัจจุบันอยู่ภายใต้นโยบายเศรษฐกิจดิจิทัล การทำเป็นไม่รู้ไม่ชี้หรือไม่สนใจนั้นไม่สามารถทำได้อีกต่อไป PDPA มีมาตรา 81 ที่ระบุถึงความรับผิดชอบของกรรมการผู้จัดการหรือผู้มีอำนาจสั่งการ หากมีการสั่งการให้ลูกน้องฝ่าฝืน PDPA หรือแม้แต่ไม่ได้สั่งการแต่ปล่อยปละละเลย

ดังนั้น ผู้บริหารจึงต้องมีความเข้าใจในเรื่องธรรมาภิบาล (Governance) ในการกำกับดูแลการใช้ข้อมูล และมีสำนึกในการแต่งตั้งเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (Data Protection Officer - DPO) หรือคณะทำงานที่เกี่ยวข้อง เพื่อให้มั่นใจว่าองค์กรจะไม่ละเมิดข้อมูลส่วนบุคคลของผู้อื่น ไม่ว่าจะเป็นพนักงานภายในองค์กร (ซึ่งถือเป็นลูกค้าภายใน) หรือผู้บริโภคภายนอก (ซึ่งเป็นลูกค้าภายนอก)

การมี DPO หรือคณะทำงานที่เข้าใจบทบาทหน้าที่ของตนเองเป็นสิ่งสำคัญอย่างยิ่ง เพราะพวกเขาจะทำหน้าที่เป็นอัศวินโต๊ะกลมที่คอยให้คำแนะนำและตรวจสอบเพื่อให้องค์กรปฏิบัติตาม PDPA ได้อย่างถูกต้อง

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

บทสรุป

การสัมมนา "PDPA Guru: รู้ชัด ปฏิบัติชัวร์ - ในฐานะผู้ประมวลผลข้อมูลส่วนบุคคล (Data Processor)" ได้ให้ความรู้และแนวทางปฏิบัติที่สำคัญสำหรับองค์กรที่เกี่ยวข้องกับการประมวลผลข้อมูลส่วนบุคคลในฐานะ Data Processor โดยสรุปประเด็นสำคัญได้ดังนี้:

1. ความเข้าใจบทบาท: การแยกแยะความแตกต่างระหว่าง Data Controller และ Data Processor เป็นสิ่งสำคัญ Data Controller เป็นผู้กำหนดวัตถุประสงค์และวิธีการประมวลผล ส่วน Data Processor ทำตามคำสั่งเท่านั้น ความรับผิดชอบหลักยังคงอยู่ที่ Data Controller

2. การเลือกใช้ข้อตกลง: การเลือกใช้ Data Processing Agreement (DPA) หรือ Data Sharing Agreement (DSA) ต้องพิจารณาจากสถานะของคู่สัญญา (เป็นนิติบุคคลเดียวกันหรือไม่) และลักษณะของกิจกรรมการประมวลผลข้อมูล หากเป็นการว่าจ้างให้ประมวลผลตามคำสั่งอย่างเคร่งครัด ควรใช้ DPA แต่หากเป็นการแบ่งปันข้อมูลระหว่าง Data Controller ด้วยกันเอง ควรใช้ DSA

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

4. มาตรการคุ้มครองข้อมูล: องค์กรต้องวางมาตรการคุ้มครองข้อมูลส่วนบุคคลอย่างรอบด้าน ทั้งเชิงนโยบาย (เช่น Privacy Policy, การฝึกอบรม) เชิงเทคนิค (เช่น Cyber Security, การควบคุมการเข้าถึง) และเชิงกายภาพ (เช่น การควบคุมการเข้าถึงห้อง Server) โดยระดับความเข้มข้นของมาตรการขึ้นอยู่กับความอ่อนไหวของข้อมูลและลักษณะธุรกิจ

5. ความรับผิดชอบกรณีข้อมูลรั่วไหล: หากองค์กรได้วางมาตรการคุ้มครองข้อมูลอย่างครบถ้วนแล้ว แต่ข้อมูลยังคงรั่วไหลโดยแฮกเกอร์ องค์กรอาจไม่ผิด PDPA ในส่วนของโทษทางปกครอง แต่ยังคงต้องรับผิดชอบตามกฎหมายอื่นหรือข้อตกลงที่ทำไว้กับลูกค้า

6. หลัก Accountability: ผู้บริหารทุกคนต้องมีสำนึกรับผิดชอบและตระหนักถึงความสำคัญของการคุ้มครองข้อมูลส่วนบุคคล การแต่งตั้ง DPO หรือคณะทำงานที่เกี่ยวข้องเป็นสิ่งจำเป็น เพื่อให้องค์กรสามารถแสดงความรับผิดชอบในการปฏิบัติตาม PDPA ได้อย่างแท้จริง