ISO 27701:2025 คือมาตรฐานระบบบริหารจัดการความเป็นส่วนตัวที่ฉบับใหม่ใช้ได้เองโดยไม่ต้องมี ISO 27001 ก่อน และงาน PDPA หลายชิ้นนับเป็นหลักฐานได้ บทความนี้เหมาะกับ DPO และทีม PDPA ที่ถูกถามหา ISO 27701 ได้แผนที่ว่างานไหนใช้ได้ งานไหนยังขาด และเรื่องไหนมาจากกฎหมายไทย
- ISO/IEC 27701:2025 เป็นฉบับที่ 2 ที่แทนฉบับ 2019 และเขียนใหม่ให้ยืนได้เอง ไม่ต้องทำ ISO 27001 ให้เสร็จก่อน
- RoPA ตาม ม.39 บันทึกการปฏิเสธคำขอตาม ม.30 ทะเบียนเหตุละเมิดตาม ม.37 (4) และข้อตกลงตาม ม.40 คือหลักฐานที่ผู้ตรวจ ISO 27701 ขอดู
- งาน PDPA ไม่ได้สร้างตัวระบบบริหารให้ ขอบเขต นโยบาย เป้าหมาย SoA การตรวจภายใน และการทบทวนโดยผู้บริหาร ต้องทำเพิ่ม
- ISO 27701 ไม่มีตัวเลข 72 ชั่วโมง 30 วัน 15 วัน หรือเกณฑ์อายุ 10 ปีตาม ม.20 ตัวเลขเหล่านี้มาจากกฎหมายไทยเท่านั้น
- บทบาทผู้ควบคุมหรือผู้ประมวลผลตาม PDPA เป็นตัวกำหนดว่าต้องใช้มาตรการ Annex A หมวดไหนจาก 78 ข้อ
ทีม PDPA ของบริษัทไทยหลายแห่งเริ่มเจอคำถามเดียวกันจากลูกค้าต่างชาติหรือฝ่ายจัดซื้อของคู่ค้ารายใหญ่ ว่าบริษัทมี ISO 27701 หรือยัง คำตอบที่ได้ยินบ่อยในห้องประชุมคือ ต้องทำ ISO 27001 ให้เสร็จก่อน ซึ่งเคยถูกสำหรับฉบับ 2019 แต่ใช้กับฉบับ 2025 ไม่ได้แล้ว
บทความนี้ไม่ได้สรุป ISO 27701 ทั้งเล่ม แต่หยิบหน้าที่ตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) มาวางทีละข้อ เทียบกับสิ่งที่ผู้ตรวจ ISO 27701 จะขอดู เพื่อให้เห็นว่างานที่ทำไปแล้วใช้ต่อได้แค่ไหน อะไรยังต้องทำเพิ่มในฝั่ง ISO และอะไรที่มาตรฐานไม่มีวันให้ เพราะเป็นเรื่องเฉพาะของกฎหมายไทย
ISO 27701:2025 ต่างจากฉบับ 2019 ตรงไหน?
ต่างกันที่จุดตั้งต้น ฉบับ 2019 เป็นส่วนขยายที่ต่อยอดจาก ISO/IEC 27001 องค์กรจึงต้องมีระบบบริหารความมั่นคงปลอดภัยสารสนเทศเป็นฐานก่อน ส่วนฉบับที่ 2 ซึ่งพิมพ์เดือนตุลาคม 2025 ยกเลิกและแทนฉบับเดิม โดยคำนำของมาตรฐานระบุว่าเปลี่ยนหลักคือเขียนใหม่ให้เป็นมาตรฐานระบบบริหารที่ยืนได้ด้วยตัวเอง
ในทางปฏิบัติ ISO 27701:2025 มีข้อกำหนดระบบบริหารครบอยู่ในเล่มเดียว ตั้งแต่บริบทขององค์กร ภาวะผู้นำ การวางแผน การสนับสนุน การดำเนินงาน การประเมินผล ไปจนถึงการปรับปรุง (ข้อ 4 ถึงข้อ 10) องค์กรที่มี ISO 27001 อยู่แล้วยังรวมสองระบบเข้าด้วยกันได้ เพียงแต่ไม่ใช่เงื่อนไขอีกต่อไป
ของที่ยังขาดไม่ได้คือโปรแกรมความมั่นคงปลอดภัยสารสนเทศ ข้อ 6.1.3 ให้องค์กรระบุและบันทึกโปรแกรมนี้ไว้ โดยไล่หัวข้อขั้นต่ำ เช่น การควบคุมการเข้าถึง การดูแลซัพพลายเออร์ การจัดการเหตุ ความต่อเนื่อง และการเข้ารหัส จะอิง ISO 27001 หรือเป็นชุดมาตรการที่องค์กรออกแบบเองก็ได้
หนังสือคู่มือ ITGP 2025 (สรุปไว้ในบันทึกของทีม AIPDPA) ตั้งข้อสังเกตว่าการแยกเล่มทำให้เรื่องภาวะผู้นำ การวางแผน และการปรับปรุงด้านข้อมูลส่วนบุคคล ถูกตรวจจริงจังกว่าเดิม
งาน PDPA ชิ้นไหนที่ผู้ตรวจ ISO 27701 จะขอดู?
งานบันทึกเกือบทุกชิ้นที่ PDPA บังคับ ใช้เป็นหลักฐานของมาตรการใน Annex A ได้ โดยเฉพาะ RoPA ระบบรับคำขอใช้สิทธิ ทะเบียนเหตุละเมิด และข้อตกลงกับผู้ประมวลผล เงื่อนไขคือต้องเป็นของที่ใช้งานจริงและมีร่องรอยวันที่ ไม่ใช่ไฟล์นโยบายที่เขียนไว้แล้วไม่มีใครเปิด
ตารางข้างล่างเป็นแผนที่ที่ทีม AIPDPA เทียบเอง ตัวมาตรฐานมีตารางเทียบกับ ISO/IEC 29100 และ GDPR ของสหภาพยุโรป แต่ไม่มีตารางเทียบกับ PDPA จึงควรอ่านเป็นการชี้ว่าหลักฐานอยู่ตรงไหน ไม่ใช่ความเห็นทางกฎหมาย
| หน้าที่ตาม PDPA | ตัวบท | ส่วนของ ISO 27701 ที่เกี่ยว | หลักฐานที่ผู้ตรวจมักขอดู | ช่องว่างที่พบบ่อย |
|---|---|---|---|---|
| บันทึกรายการกิจกรรมการประมวลผล (RoPA) | ม.39 (ผู้ควบคุม) · ม.40 (3) (ผู้ประมวลผล) | B.1.2.9 บันทึกการประมวลผล · B.2.2.7 ฝั่งผู้ประมวลผล | ทะเบียนกิจกรรมที่มีเจ้าของรับผิดชอบความถูกต้อง ระบุฐานทางกฎหมายรายกิจกรรม | ไม่มีชื่อเจ้าของทะเบียน ไม่รู้ว่าทบทวนครั้งล่าสุดเมื่อไร |
| ตอบคำขอใช้สิทธิของเจ้าของข้อมูล | ม.30–ม.36 (ม.30 ตอบภายใน 30 วัน) | B.1.3 หน้าที่ต่อเจ้าของข้อมูล · B.1.3.10 การจัดการคำขอ | ขั้นตอนรับคำขอที่เขียนไว้ บันทึกคำขอจริงพร้อมวันรับและวันตอบ บันทึกการปฏิเสธพร้อมเหตุผล | มีแบบฟอร์มรับคำขอ แต่ไม่มีบันทึกว่าตอบเมื่อไร |
| แจ้งเหตุละเมิดข้อมูล | ม.37 (4) · ประกาศแจ้งเหตุ 2565 | B.3.11–B.3.12 การเตรียมและการตอบสนองต่อเหตุ | แผนรับมือเหตุ ทะเบียนเหตุทุกครั้ง รวมเหตุที่ประเมินแล้วว่าไม่ต้องแจ้ง หลักฐานการแจ้ง | เก็บเฉพาะเหตุที่แจ้ง สคส. เหตุที่ตัดสินว่าไม่แจ้งไม่มีเหตุผลเก็บไว้ |
| ข้อตกลงกับผู้ประมวลผล | ม.40 วรรคสาม · ข้อ 8 ประกาศแจ้งเหตุ | B.1.2.7 สัญญากับผู้ประมวลผล · A.2/B.2 ฝั่งผู้ประมวลผล · B.3.10 ข้อตกลงกับซัพพลายเออร์ | สัญญาหรือ DPA ที่ระบุมาตรการและหน้าที่แจ้งเหตุ รายชื่อผู้ประมวลผลช่วง | สัญญารุ่นเก่าไม่มีข้อแจ้งเหตุภายใน 72 ชั่วโมง |
| มาตรการรักษาความมั่นคงปลอดภัย | ม.37 (1) · ม.40 (2) | 6.1.3 โปรแกรมความมั่นคงปลอดภัย · A.3/B.3 | บัญชีสิทธิ์เข้าถึง log ผลทดสอบกู้คืนข้อมูลสำรอง ผลทบทวนมาตรการ | ทำมาตรการแล้ว แต่ไม่มีบันทึกว่าทบทวนเมื่อไร |
| ประเมินผลกระทบ (DPIA) | ไม่มีมาตราบังคับตรง ๆ · ทำคู่กับ ม.37 (1) เป็นแนวปฏิบัติที่ดี | B.1.2.6 การประเมินผลกระทบด้านความเป็นส่วนตัว · 6.1.2 การประเมินความเสี่ยง | เกณฑ์ว่าเมื่อไรต้องทำ รายงาน DPIA ของกิจกรรมเสี่ยงสูง | ทำครั้งเดียวตอนเริ่มโครงการ ไม่ทำซ้ำเมื่อระบบเปลี่ยน |
| ความยินยอมและประกาศความเป็นส่วนตัว | ม.19 · ม.20 · ม.23 | B.1.2.4–B.1.2.5 ความยินยอม · B.1.3.3–B.1.3.4 การแจ้งข้อมูล | บันทึกความยินยอมรายคน ประกาศฉบับที่ใช้จริงพร้อมวันที่ | มีความยินยอม แต่ตอบไม่ได้ว่าผู้ใช้เห็นประกาศฉบับไหน |
RoPA: ของที่ มาตรา 39 บังคับให้มีอยู่แล้ว
ให้ผู้ควบคุมข้อมูลส่วนบุคคลบันทึกรายการ อย่างน้อยดังต่อไปนี้ เพื่อให้เจ้าของข้อมูลส่วนบุคคลและสำนักงานสามารถตรวจสอบได้ โดยจะบันทึกเป็นหนังสือหรือระบบอิเล็กทรอนิกส์ก็ได้
RoPA ที่ทำครบตามมาตรา 39 มีหน้าตาใกล้กับทะเบียนกิจกรรมที่ ISO 27701 แนะนำไว้ในแนวทาง B.1.2.9 อยู่แล้ว ทั้งประเภทข้อมูล วัตถุประสงค์ และคำอธิบายมาตรการความปลอดภัยตามมาตรา 39 (8) สิ่งที่ ISO ถามเพิ่มคือทะเบียนนี้มีเจ้าของที่รับผิดชอบความถูกต้องและครบถ้วนหรือไม่ และระบุฐานทางกฎหมายไว้รายกิจกรรมหรือเปล่า
จุดที่ต้องระวังคือวรรคท้ายของมาตรา 39 เปิดให้กิจการขนาดเล็กอาจได้รับยกเว้นบางรายการตามหลักเกณฑ์ที่คณะกรรมการประกาศ ISO ไม่มีข้อยกเว้นทำนองนี้ ถ้าองค์กรขีดขอบเขตระบบให้ครอบคลุมกิจกรรมใด ควรเตรียมบันทึกของกิจกรรมนั้นให้ครบตามที่ตัวเองวางไว้ ดูวิธีเก็บข้อมูลจากแต่ละฝ่ายได้ที่ คู่มือทำ RoPA
คำขอใช้สิทธิ: ISO ให้กำหนดเวลาเอง PDPA กำหนดให้แล้ว
แนวทาง B.1.3.10 ของ ISO 27701 บอกเพียงว่าคำขอของเจ้าของข้อมูลควรตอบภายในเวลาที่องค์กรกำหนด และให้เขียนเวลานั้นไว้ในนโยบายความเป็นส่วนตัว ตัวเลขจริงจึงต้องมาจากกฎหมาย สำหรับคำขอเข้าถึงและขอรับสำเนา มาตรา 30 วรรคสี่ของ PDPA เขียนไว้ดังนี้
ให้ผู้ควบคุมข้อมูลส่วนบุคคลดำเนินการตามคำขอโดยไม่ชักช้า แต่ต้องไม่เกินสามสิบวันนับแต่วันที่ได้รับคำขอ
ในกรณีที่ผู้ควบคุมข้อมูลส่วนบุคคลปฏิเสธคำขอตามวรรคหนึ่ง ให้ผู้ควบคุมข้อมูลส่วนบุคคลบันทึกการปฏิเสธคำขอดังกล่าวพร้อมด้วยเหตุผลไว้ในรายการตามมาตรา 39
มาตรา 30 วรรคสามช่วยได้มากเวลาถูกตรวจ เพราะผูกคำขอที่ถูกปฏิเสธเข้ากับ RoPA โดยตรง ถ้าผู้ตรวจ ISO สุ่มคำขอสักสองสามรายการ องค์กรที่เก็บครบตามมาตรา 30 จะเปิดให้ดูได้ทั้งวันรับ วันตอบ และเหตุผลกรณีปฏิเสธ แทบไม่ต้องเตรียมอะไรเพิ่ม ดูวิธีจัดการคำขอให้ทัน 30 วันได้ที่ บทความเรื่องคำขอใช้สิทธิ
เหตุละเมิด: ทะเบียนต้องมีทั้งเหตุที่แจ้งและเหตุที่ไม่แจ้ง
แจ้งเหตุการละเมิดข้อมูลส่วนบุคคลแก่สำนักงานโดยไม่ชักช้าภายในเจ็ดสิบสองชั่วโมงนับแต่ทราบเหตุเท่าที่จะสามารถกระทำได้ เว้นแต่การละเมิดดังกล่าวไม่มีความเสี่ยงที่จะมีผลกระทบต่อสิทธิและเสรีภาพของบุคคล
แนวทาง B.3.12 ของ ISO 27701 ให้เหตุทุกครั้งที่เกี่ยวกับข้อมูลส่วนบุคคลผ่านการทบทวนว่าเข้าข่ายการละเมิดที่ต้องตอบสนองหรือไม่ และให้เก็บบันทึกที่ละเอียดพอจะทำรายงานต่อหน่วยงานกำกับได้ เช่น ช่วงเวลา ผลที่เกิด ผู้รายงาน และขั้นตอนแก้ไข แต่มาตรฐานไม่ได้กำหนดจำนวนชั่วโมง กรอบ 72 ชั่วโมงนับแต่ทราบเหตุมาจากมาตรา 37 (4) ของ PDPA
ข้อยกเว้นท้ายมาตรา 37 (4) คือการละเมิดที่ไม่มีความเสี่ยงต่อสิทธิและเสรีภาพของบุคคล ข้อ 9 ของประกาศหลักเกณฑ์แจ้งเหตุ 2565 ให้ผู้ควบคุมข้อมูลเป็นฝ่ายพิสูจน์และส่งหลักฐานประกอบ เหตุที่ตัดสินว่าไม่แจ้งจึงต้องมีบันทึกเหตุผล ซึ่งเป็นชิ้นเดียวกับที่ผู้ตรวจ ISO ขอดู
ลำดับงานช่วงแรกหลังเกิดเหตุดูได้ที่ 72 ชั่วโมงแรกหลังข้อมูลรั่ว
ผู้ประมวลผล: สัญญาฉบับเดียวต้องตอบทั้งสองฝั่ง
ผู้ควบคุมข้อมูลส่วนบุคคลต้องจัดให้มีข้อตกลงระหว่างกัน เพื่อควบคุมการดำเนินงานตามหน้าที่ของผู้ประมวลผลข้อมูลส่วนบุคคลให้เป็นไปตามพระราชบัญญัตินี้
ผู้ควบคุมข้อมูลส่วนบุคคลจะต้องระบุไว้ในข้อตกลงหรือในสัญญาที่เกี่ยวข้องให้ผู้ประมวลผลข้อมูลส่วนบุคคลมีหน้าที่แจ้งเหตุการละเมิดข้อมูลส่วนบุคคลแก่ผู้ควบคุมข้อมูลส่วนบุคคลโดยไม่ชักช้าภายในเจ็ดสิบสองชั่วโมงนับแต่ผู้ประมวลผลข้อมูลส่วนบุคคลทราบเหตุเท่าที่จะสามารถกระทำได้เช่นกัน
ฝั่ง ISO แนวทาง B.1.2.7 ให้สัญญากับผู้ประมวลผลครอบคลุมมาตรการในตาราง A.2 โดยตั้งต้นว่าทุกข้อเกี่ยวข้อง ถ้าจะไม่ให้ผู้ประมวลผลทำข้อใดต้องเขียนเหตุผล ส่วนแนวทาง B.3.12 ฝั่งผู้ประมวลผลแนะนำให้สัญญาระบุกรอบเวลาการแจ้งเหตุไว้
สัญญาที่เขียนเลข 72 ชั่วโมงตามข้อ 8 ของประกาศจึงปิดได้ทั้งสองเรื่องในข้อเดียว รายการข้อสัญญาที่ควรมีดูได้ที่ ข้อตกลงกับผู้ประมวลผล
มาตรการความปลอดภัย: ต้องเห็นว่ามีการทบทวนจริง
จัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม เพื่อป้องกันการสูญหาย เข้าถึง ใช้ เปลี่ยนแปลง แก้ไข หรือเปิดเผยข้อมูลส่วนบุคคลโดยปราศจากอำนาจหรือโดยมิชอบ และต้องทบทวนมาตรการดังกล่าวเมื่อมีความจำเป็นหรือเมื่อเทคโนโลยีเปลี่ยนแปลงไป
คำว่า ต้องทบทวน ในมาตรา 37 (1) ตรงกับสิ่งที่ผู้ตรวจ ISO มองหา คือหลักฐานว่ามาตรการไม่ได้ทำครั้งเดียวแล้วจบ เช่น ผลทบทวนสิทธิ์เข้าถึงระบบตามรอบ หรือบันทึกการทดสอบกู้คืนข้อมูลสำรอง มาตรการชุดนี้คือแกนของโปรแกรมความมั่นคงปลอดภัยที่ข้อ 6.1.3 ให้บันทึกไว้
มาตรา 37 (1) ยังให้มาตรการเป็นไปตามมาตรฐานขั้นต่ำที่คณะกรรมการประกาศกำหนด ซึ่งเป็นเรื่องของไทยโดยเฉพาะ โปรแกรมความปลอดภัยที่ออกแบบตาม ISO ควรเทียบกับประกาศฉบับนั้นอีกชั้น ดูรายการตรวจได้ที่ มาตรฐานขั้นต่ำด้านความมั่นคงปลอดภัย
DPIA: PDPA ไม่ได้สั่งตรง ๆ แต่ ISO ถามแน่
PDPA ไม่มีมาตราที่สั่งให้ทำ DPIA ไว้ตรง ๆ ส่วน ISO 27701 แนวทาง B.1.2.6 ให้องค์กรพิจารณาว่าต้องประเมินผลกระทบหรือไม่ทุกครั้งที่จะเริ่มการประมวลผลใหม่หรือเปลี่ยนของเดิม พร้อมยกเกณฑ์ตัวอย่าง เช่น การตัดสินใจอัตโนมัติที่มีผลทางกฎหมายต่อบุคคล การประมวลผลข้อมูลอ่อนไหวจำนวนมาก และการเฝ้าติดตามพื้นที่สาธารณะในวงกว้าง
องค์กรที่ทำ DPIA เป็นแนวปฏิบัติที่ดีอยู่แล้วจึงได้เปรียบ สิ่งที่ควรเพิ่มคือเกณฑ์ที่เขียนไว้ว่าเมื่อไรต้องทำ และบันทึกว่ากิจกรรมที่ประเมินแล้วไม่ต้องทำ ตัดสินด้วยเหตุผลอะไร ขั้นตอนทำ RoPA กับ DPIA ให้จบดูได้ที่ บทความนี้
ใน AIPDPA มาตรการ 78 ข้อของ ISO 27701 อยู่บนกระดานหลักฐานเดียวกับ PDPA, ISO 27001 (93 ข้อ), ISO 42001 (38 ข้อ), NIST AI RMF (72 ข้อ) และแนวปฏิบัติของ สคส. งาน RoPA หรือคำขอใช้สิทธิที่ทำครั้งเดียวจึงนับเป็นหลักฐานได้ทุกมาตรฐานที่เกี่ยว
สถานะบนกระดานหลักฐานของ AIPDPA คำนวณใหม่ทุกครั้งที่เปิด ทุกคืนระบบเตือนหลักฐานที่จะหมดอายุใน 30 วันและบันทึกคะแนนความพร้อมรายวัน ส่วนคำยืนยันของผู้ใช้อย่างเดียวได้สถานะสูงสุดแค่บางส่วน กระดานนี้เริ่มที่แพ็กเกจ GROWTH
งาน PDPA ขาดอะไรที่ ISO 27701 ต้องการ?
สิ่งที่ขาดแทบทุกองค์กรคือตัวระบบบริหาร PDPA สั่งให้ทำงานแต่ละชิ้น แต่ไม่ได้สั่งให้มีวงจรวางแผน ตรวจ และปรับปรุงทั้งระบบ ซึ่งเป็นครึ่งหนึ่งของ ISO 27701 และเป็นส่วนที่ทีม PDPA ส่วนใหญ่ไม่มีเอกสารรองรับเลย
| ข้อของ ISO 27701 | ต้องมีอะไร | งาน PDPA ช่วยได้ไหม |
|---|---|---|
| 4.2 ผู้มีส่วนได้เสีย | ระบุผู้มีส่วนได้เสียและความต้องการของเขา โดยต้องนับเจ้าของข้อมูลรวมด้วย | ช่วยได้บางส่วน ถ้า RoPA ระบุกลุ่มเจ้าของข้อมูลไว้แล้ว |
| 4.3 ขอบเขตระบบ | ขอบเขตที่บันทึกเป็นเอกสาร และต้องรวมการประมวลผลข้อมูลส่วนบุคคล | ไม่ช่วย PDPA ใช้กับทุกกิจกรรมอยู่แล้ว จึงไม่เคยต้องขีดขอบเขต |
| 5.2 นโยบายความเป็นส่วนตัว | นโยบายระดับองค์กรที่ผู้บริหารสูงสุดออก มีคำมั่นว่าจะทำตามข้อกำหนดและปรับปรุงต่อเนื่อง | มักมีแค่ประกาศความเป็นส่วนตัวสำหรับลูกค้า ซึ่งเป็นคนละเอกสาร |
| 6.1.2–6.1.3 ความเสี่ยงและ SoA | ประเมินความเสี่ยงทั้งต่อองค์กรและต่อเจ้าของข้อมูล เลือกมาตรการ แล้วทำ SoA ว่าข้อไหนจำเป็น ทำแล้วหรือยัง และเหตุผลที่ตัดข้อใน Annex A ออก | DPIA ช่วยได้บางส่วน แต่ไม่ใช่ SoA |
| 6.2 เป้าหมายด้านความเป็นส่วนตัว | เป้าหมายที่สอดคล้องกับนโยบาย วัดได้ถ้าทำได้ มีผู้รับผิดชอบและกำหนดเสร็จ | ไม่ช่วย |
| 9.2 การตรวจภายใน | แผนตรวจตามรอบ ผู้ตรวจที่เป็นกลาง และรายงานผลถึงผู้บริหารที่เกี่ยวข้อง | ไม่ช่วย |
| 9.3 การทบทวนโดยผู้บริหาร | ประชุมตามรอบโดยมีหัวข้อขั้นต่ำตามข้อ 9.3.2 เช่น งานค้างจากรอบก่อน ผลตรวจ ข้อบกพร่องและการแก้ไข พร้อมบันทึกผลการตัดสินใจ | ไม่ช่วย |
| 10.2 ข้อบกพร่องและการแก้ไข | บันทึกลักษณะข้อบกพร่อง สาเหตุ การแก้ไข และผลของการแก้ไข | ช่วยได้บางส่วน ถ้าทะเบียนเหตุละเมิดบันทึกการแก้ไขไว้ |
ชิ้นงานกลุ่มนี้อยู่ในแพ็กเกจ ENTERPRISE ของ AIPDPA ครบชุด ตั้งแต่ทะเบียนความเสี่ยงแบบ 5×5 เป้าหมาย แผนตรวจภายในตามความเสี่ยง วาระทบทวนโดยผู้บริหารตามหัวข้อในข้อ 9.3.2 SoA ที่ส่งออกเป็นไฟล์ Word ไปจนถึงการซ้อมตรวจแบบสองขั้น
AIPDPA ช่วยเตรียมหลักฐาน ส่วนการรับรองยังต้องผ่านหน่วยรับรองที่องค์กรเลือกเอง ดูวิธีเตรียมตัวได้ที่ คู่มือเตรียมรับการตรวจ ISO
ISO 27701 ไม่ได้ให้อะไรที่กฎหมายไทยบังคับ?
ISO เขียนให้ใช้ได้ทั่วโลก จึงพูดถึงกฎหมายท้องถิ่นเพียงว่าบางประเทศอาจกำหนดเงื่อนไขไว้ ตัวเลขและเงื่อนไขเฉพาะของไทยต้องหยิบจาก PDPA และประกาศเอง องค์กรที่ผ่านการตรวจ ISO 27701 แล้วจึงยังต้องตรวจจุดเหล่านี้แยกต่างหาก
ISO ให้มีขั้นตอนแจ้งเหตุและบันทึก แต่ไม่มีจำนวนชั่วโมง ทะเบียนเหตุต้องมีเวลาที่ทราบเหตุ จึงจะนับเส้นตายตามกฎหมายไทยได้
ขอให้ สคส. พิจารณายกเว้นความผิดได้ โดยชี้แจงเหตุจำเป็น และต้องแจ้งไม่เกิน 15 วันนับแต่ทราบเหตุ ISO ไม่มีกลไกนี้
ISO แนะนำให้สัญญากำหนดกรอบเวลาเอง ประกาศไทยกำหนดตัวเลข 72 ชั่วโมงไว้ให้แล้ว และสั่งให้ผู้ควบคุมเขียนลงสัญญา
ISO บอกเพียงว่าเด็กอาจมีข้อกำหนดเพิ่ม ส่วน ม.20 แยกกรณีที่ต้องได้ความยินยอมจากผู้ใช้อำนาจปกครอง และกรณีผู้เยาว์อายุไม่เกิน 10 ปี
ISO ให้องค์กรกำหนดเวลาตอบเอง ตัวเลขไม่เกิน 30 วันนับแต่วันที่ได้รับคำขอมาจาก PDPA
มาตรการต้องเป็นไปตามมาตรฐานขั้นต่ำที่คณะกรรมการประกาศ โปรแกรมความปลอดภัยแบบ ISO ต้องเทียบกับประกาศนั้นด้วย
(2) ในกรณีที่ผู้เยาว์มีอายุไม่เกินสิบปี ให้ขอความยินยอมจากผู้ใช้อำนาจปกครองที่มีอำนาจกระทำการแทนผู้เยาว์
ในตัวมาตรฐานไม่มีเกณฑ์อายุแบบนี้ ระบบเก็บความยินยอมที่ผ่านการตรวจ ISO แล้วจึงอาจยังไม่ถามอายุ หรือไม่ได้แยกผู้ใช้ที่เป็นเด็กออกมา ทั้งที่มาตรา 20 วรรคท้ายให้นำหลักเดียวกันไปใช้กับการถอนความยินยอมและการใช้สิทธิด้วย ดูรายละเอียดที่ ข้อมูลเด็กและความยินยอมของผู้ปกครอง
โดยจะต้องแจ้งแก่สำนักงานโดยเร็ว ทั้งนี้ ต้องไม่เกินสิบห้าวันนับแต่ทราบเหตุ
ข้อ 7 เป็นกลไกเฉพาะของไทย ทะเบียนเหตุละเมิดที่ออกแบบตาม ISO อย่างเดียวมักไม่มีช่องเก็บเหตุผลของการแจ้งช้า ควรเพิ่มช่องนี้ไว้ตั้งแต่วันแรก เพราะเมื่อเกิดเหตุจริงจะไม่มีเวลามานั่งออกแบบฟอร์ม
เป็นผู้ควบคุมหรือผู้ประมวลผล ต้องใช้ Annex A หมวดไหน?
บทบาทตาม PDPA เป็นตัวกำหนดหมวดมาตรการ ISO 27701 แบ่ง Annex A เป็นสามหมวด คือหมวดสำหรับผู้ควบคุมข้อมูลส่วนบุคคล หมวดสำหรับผู้ประมวลผลข้อมูลส่วนบุคคล และหมวดความมั่นคงปลอดภัยที่ใช้ทั้งสองบทบาท บริษัทเดียวเป็นได้ทั้งสองบทบาทในคนละกิจกรรม เช่น เป็นผู้ควบคุมข้อมูลพนักงานของตัวเอง แต่เป็นผู้ประมวลผลข้อมูลที่ลูกค้าส่งมาให้
| หมวด | ใช้กับ | จำนวนมาตรการ | หน้าที่ PDPA ที่เทียบได้ |
|---|---|---|---|
| A.1 (แนวทาง B.1) | ผู้ควบคุมข้อมูลส่วนบุคคล | 31 | ฐานทางกฎหมาย ม.24 ม.26 · ความยินยอม ม.19 · สิทธิ ม.30–ม.36 · RoPA ม.39 · ส่งข้อมูลไปต่างประเทศ ม.28–ม.29 |
| A.2 (แนวทาง B.2) | ผู้ประมวลผลข้อมูลส่วนบุคคล | 18 | หน้าที่ผู้ประมวลผล ม.40 |
| A.3 (แนวทาง B.3) | ทั้งสองบทบาท | 29 | มาตรการความปลอดภัย ม.37 (1) ม.40 (2) · เหตุละเมิด ม.37 (4) |
ผู้ประมวลผลข้อมูลส่วนบุคคลซึ่งไม่ปฏิบัติตาม (1) สำหรับการเก็บรวบรวม ใช้ หรือเปิดเผยข้อมูลส่วนบุคคลใด ให้ถือว่าผู้ประมวลผลข้อมูลส่วนบุคคลเป็นผู้ควบคุมข้อมูลส่วนบุคคลสำหรับการเก็บรวบรวม ใช้ หรือเปิดเผยข้อมูลส่วนบุคคลนั้น
ข้อนี้สำคัญกับบริษัทรับจ้างประมวลผล เช่น ผู้ให้บริการคลาวด์ คอลเซ็นเตอร์ หรือบริษัทซอฟต์แวร์ ถ้าเอาข้อมูลของลูกค้าไปใช้นอกคำสั่ง กฎหมายไทยถือว่าเป็นผู้ควบคุมสำหรับการใช้นั้น เรื่องนี้ตรงกับมาตรการฝั่งผู้ประมวลผลใน ISO ที่ให้ใช้ข้อมูลตามคำสั่งที่เป็นลายลักษณ์อักษรของลูกค้าเท่านั้น และห้ามนำไปทำการตลาดโดยไม่มีความยินยอมจากเจ้าของข้อมูลก่อน
บริษัทที่เป็นผู้ควบคุมอย่างเดียวยังต้องดูแลผู้ประมวลผลของตัวเองผ่านสัญญาตามแนวทาง B.1.2.7 และมาตรา 40 วรรคสาม กรณีผู้ควบคุมร่วม มาตรฐานมีแนวทาง B.1.2.8 ให้ตกลงบทบาทของแต่ละฝ่ายเป็นลายลักษณ์อักษร รวมถึงว่าใครเป็นคนแจ้งเมื่อเกิดเหตุละเมิด
ทีม PDPA ควรเริ่ม ISO 27701 จากตรงไหน?
- เขียนให้ชัดว่าองค์กรเป็นผู้ควบคุม ผู้ประมวลผล หรือทั้งสองบทบาท ในกิจกรรมไหนบ้าง โดยใช้ RoPA เป็นตัวตั้ง
- ขีดขอบเขตระบบตามข้อ 4.3 จะเริ่มทั้งองค์กรหรือเฉพาะบริการที่ลูกค้าถามหาใบรับรองก็ได้ แต่ขอบเขตนั้นต้องรวมการประมวลผลข้อมูลส่วนบุคคล
- ไล่ตารางแผนที่หลักฐานข้างบน ทำเครื่องหมายว่าชิ้นไหนมีและใช้งานจริง ชิ้นไหนมีแต่ไม่มีร่องรอยวันที่
- ประเมินความเสี่ยงทั้งต่อองค์กรและต่อเจ้าของข้อมูล แล้วทำ SoA พร้อมเหตุผลของข้อที่ตัดออก
- ตั้งเป้าหมายด้านความเป็นส่วนตัว 3–5 ข้อที่วัดได้ เช่น สัดส่วนคำขอที่ตอบทันกำหนด หรือจำนวนสัญญาผู้ประมวลผลที่มีข้อแจ้งเหตุ
- ตรวจภายในหนึ่งรอบ แล้วนำผลเข้าที่ประชุมทบทวนโดยผู้บริหาร ก่อนติดต่อหน่วยรับรอง
ขั้นที่ 1 ถึง 3 ใช้ของที่ทีม PDPA มีอยู่แล้วเกือบทั้งหมด งานหนักจริงอยู่ที่ขั้นที่ 4 ถึง 6 ซึ่งเป็นงานของระบบบริหาร และเป็นเหตุที่องค์กรซึ่งทำ PDPA มาดีแล้วไม่ควรประเมินว่า ISO 27701 จะเสร็จในเดือนเดียว ภาพรวมของมาตรฐานอ่านได้ที่ คู่มือ ISO 27701
คำถามที่พบบ่อย
ISO 27701:2025 ต้องมี ISO 27001 ก่อนไหม?
ไม่ต้อง ฉบับ 2025 เขียนใหม่เป็นมาตรฐานระบบบริหารที่ใช้ได้ด้วยตัวเอง แต่ยังต้องมีโปรแกรมความมั่นคงปลอดภัยสารสนเทศที่บันทึกไว้ตามข้อ 6.1.3 จะอิง ISO 27001 หรือออกแบบเองก็ได้
ได้ใบรับรอง ISO 27701 แล้ว ถือว่าทำตาม PDPA ครบหรือยัง?
ยัง ISO ไม่ใช่กฎหมายไทย และไม่ได้กำหนดกรอบ 72 ชั่วโมงตาม ม.37 (4) กรอบ 30 วันตาม ม.30 หรือเงื่อนไขผู้เยาว์ตาม ม.20 ใบรับรองแสดงว่ามีระบบบริหารที่ทำงานได้ แต่หน้าที่ตาม PDPA ต้องตรวจแยก
RoPA ที่ทำตามมาตรา 39 ใช้เป็นหลักฐาน ISO 27701 ได้เลยไหม?
ใช้ได้เป็นส่วนใหญ่ ควรเพิ่มชื่อเจ้าของทะเบียนที่รับผิดชอบความถูกต้อง ฐานทางกฎหมายรายกิจกรรม และวันที่ทบทวนครั้งล่าสุด
PDPA บังคับให้ทำ DPIA ไหม?
PDPA ไม่มีมาตราที่สั่งให้ทำ DPIA ตรง ๆ แต่ ISO 27701 ให้พิจารณาความจำเป็นทุกครั้งที่มีการประมวลผลใหม่หรือเปลี่ยนแปลง การทำ DPIA สำหรับกิจกรรมเสี่ยงสูงจึงเป็นแนวปฏิบัติที่ดีที่ตอบได้ทั้งสองฝั่ง
บริษัทรับจ้างประมวลผลข้อมูลต้องใช้ Annex A หมวดไหน?
อย่างน้อยหมวด A.2 ของผู้ประมวลผลกับหมวด A.3 ที่ใช้ร่วม ถ้ามีกิจกรรมที่บริษัทกำหนดวัตถุประสงค์เอง เช่น ข้อมูลพนักงานของตัวเอง ต้องมีหมวด A.1 ด้วย
ทำไมบทความนี้ไม่ยกถ้อยคำของ ISO มาให้อ่าน?
ตัวมาตรฐาน ISO เป็นเอกสารมีลิขสิทธิ์ที่ต้องซื้อ บทความจึงเล่าเนื้อหาด้วยคำของทีมเขียนและบอกเลขข้อไว้ให้เปิดเทียบ ส่วนที่ยกคำต่อคำมีเฉพาะตัวบทกฎหมายไทย
ตัวบทและแหล่งอ้างอิง
- ISO/IEC 27701:2025 ระบบบริหารจัดการข้อมูลความเป็นส่วนตัว (PIMS) ฉบับที่ 2 · มาตรฐานสากล ไม่ใช่กฎหมายไทย · เล่าด้วยคำของทีม ไม่ได้ยกถ้อยคำ — Foreword · 0.1 · 4.2–4.3 · 5.2 · 6.1.3 · 6.2 · 9.2–9.3 · 10.2 · B.1.2.6–B.1.2.9 · B.1.3.10 · B.2.2.3–B.2.2.4 · B.3.12
- บันทึกของทีม AIPDPA จากหนังสือ ISO/IEC 27701:2025 An introduction to privacy information management systems (ITGP 2025) · ไม่ใช่กฎหมาย — บทนำ · มาตรการผู้ควบคุม 31 · ผู้ประมวลผล 18 · ใช้ร่วม 29
- พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 — มาตรา 20 · มาตรา 30 · มาตรา 37 (1) (4) · มาตรา 39 · มาตรา 40
- ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565 — ข้อ 7 · ข้อ 8 · ข้อ 9
ตัวบทที่ยกมาในกรอบ "ตัวบท" คัดคำต่อคำจากคลังกฎหมายของ AIPDPA ซึ่งถอดจากราชกิจจานุเบกษาและเอกสารของหน่วยงานรัฐ แล้วระบบตรวจทุกครั้งที่แก้บทความว่าตรงกับคลังทุกตัวอักษร · บทความนี้เป็นความรู้ทั่วไป ไม่ใช่คำปรึกษากฎหมายสำหรับกรณีใดกรณีหนึ่ง
ลงมือในระบบได้ที่
ใครรับผิดชอบเนื้อหานี้?
เรียบเรียงโดยทีมกฎหมาย AIPDPA · ผู้รับผิดชอบเนื้อหา ภูวรา ครอบตะคุ ทนายความ · เนติบัณฑิตไทย · ที่ปรึกษากฎหมายเทคโนโลยีและทรัพย์สินทางปัญญา
ใบอนุญาตทนายความ 477/2558 · เนติบัณฑิตไทย · นิติศาสตรมหาบัณฑิต กฎหมายทรัพย์สินทางปัญญาและสารสนเทศ (เหรียญทอง)