[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-faqs-pdpc-access-request-data-map-per-person-th":3,"blog-post-pdpc-access-request-data-map-per-person-th":28},[4,8,12,16,20,24],{"answer":5,"id":6,"question":7},"คือคำขอของเจ้าของข้อมูลให้องค์กรแจ้งว่าเก็บข้อมูลอะไรเกี่ยวกับตนไว้บ้าง และขอรับสำเนาข้อมูลนั้น เป็นสิทธิที่ PDPA ให้ไว้ ส่วนรายละเอียดวิธีปฏิบัติตามประกาศล่าสุด เช่น ช่องทางและกรอบเวลา ควรอ่านจากตัวประกาศหรือถามผู้รับผิดชอบด้านข้อมูลส่วนบุคคลขององค์กร","cuzih3ct1m79ai2","คำขอเข้าถึงข้อมูลส่วนบุคคลคืออะไร",{"answer":9,"id":10,"question":11},"บันทึกรายการประมวลผลบอกว่าองค์กรเก็บข้อมูลประเภทใด เพื่อวัตถุประสงค์อะไร ส่วนแผนที่ข้อมูลรายบุคคลเป็นคู่มือของทีมไอทีว่าจะค้นและดึงข้อมูลของคนคนหนึ่งจากแต่ละระบบอย่างไร ถ้ามีบันทึกอยู่แล้ว ให้ใช้เป็นจุดตั้งต้นแล้วเติมวิธีค้นกับวิธีส่งออก","o0cd0cfur3bmpz1","แผนที่ข้อมูลรายบุคคลต่างจากบันทึกรายการประมวลผลอย่างไร",{"answer":13,"id":14,"question":15},"เราไม่ได้อ่านตัวประกาศฉบับเต็ม จึงไม่ฟันธงเรื่องนี้ ในมุมระบบ ควรบันทึกไว้ในแผนที่ว่า backup และ log ของแต่ละระบบอยู่ที่ไหน ค้นได้หรือไม่ และใครมีสิทธิ์ แล้วให้ผู้รับผิดชอบด้านข้อมูลส่วนบุคคลตัดสินว่าต้องรวมหรือไม่","sfrlnbqehr3e72d","ต้องค้นข้อมูลใน backup และ log ด้วยหรือไม่",{"answer":17,"id":18,"question":19},"ควรอยู่ เพราะข้อมูลที่องค์กรส่งเข้าไปยังเกี่ยวข้องกับคำขอ ในแผนที่ให้บันทึกว่าผู้ให้บริการส่งออกข้อมูลรายบุคคลได้หรือไม่ ในรูปแบบอะไร และใครติดต่อ ส่วนบทบาทตามกฎหมายของผู้ให้บริการแต่ละราย ให้ผู้รับผิดชอบด้านข้อมูลส่วนบุคคลประเมิน","teaque4jvd44n7b","ระบบที่ผู้ให้บริการภายนอกเก็บข้อมูลให้ ต้องอยู่ในแผนที่ด้วยไหม",{"answer":21,"id":22,"question":23},"ไม่จำเป็น กระดาษหนึ่งแผ่นที่ระบุว่าข้อมูลอยู่ที่ไหน ใครเข้าถึงได้ และดึงออกมาอย่างไร ก็เป็นจุดเริ่มต้นที่ใช้ได้ เมื่อมีระบบหรือผู้ให้บริการเพิ่ม ค่อยขยายเป็นตารางเต็ม และกำหนดวันทบทวนเพื่อไม่ให้เอกสารล้าสมัย","oc3vrfjyr8i35ci","องค์กรเล็กที่มีระบบเดียวต้องทำแผนที่เต็มรูปแบบไหม",{"answer":25,"id":26,"question":27},"พิสูจน์ว่าครบทุกที่ไม่ได้ เพราะข้อมูลที่อยู่ในไฟล์หรือแชทที่ไม่มีใครบันทึกจะไม่อยู่ในแผนที่ สิ่งที่ทำได้คือบันทึกว่าค้นระบบไหนบ้าง ด้วยวิธีใด โดยใคร และส่วนที่ยังไม่รู้คือช่องว่างที่ต้องปิด","cja3a7847qo7mbq","จะรู้ได้อย่างไรว่าค้นข้อมูลของคนคนหนึ่งครบแล้ว",{"id":29,"parentId":30,"title":31,"excerpt":32,"content":33,"image":34,"date":35,"isoDate":36,"views":37,"tag":38,"categorySlug":39,"slug":40,"to":41,"readTime":42,"isHighlight":43,"sortOrder":44,"video":45,"video_id":45,"keywords":46},"1i6h2b0k3konkxq","d7a7tjxk8tnw157","ข้อมูลของคนคนเดียวอยู่ในกี่ระบบ: ทำแผนที่ข้อมูลรายบุคคลก่อนคำขอเข้าถึงข้อมูลฉบับแรกจะมาถึง","เมื่อเจ้าของข้อมูลขอสำเนาข้อมูลส่วนบุคคลของตน คำถามแรกของทีมไอทีคือข้อมูลของคนคนนั้นอยู่ที่ไหนบ้าง บทความนี้อธิบายแผนที่ข้อมูลรายบุคคล ตารางจับคู่ตัวระบุ และสิ่งที่ควรถามผู้ให้บริการภายนอก","\u003Cp>อีเมลฉบับหนึ่งเข้ามาที่กล่องข้อความของฝ่ายบริการลูกค้า ผู้ส่งเป็นลูกค้าเก่าที่ไม่ได้ซื้อของมาหลายปี เขาขอสำเนาข้อมูลส่วนบุคคลทั้งหมดที่องค์กรเก็บเกี่ยวกับตัวเขา ฝ่ายบริการลูกค้าส่งต่อเรื่องให้ทีมไอที และคำถามแรกที่ทีมไอทีต้องตอบไม่ใช่ว่าจะส่งออกไฟล์อย่างไร แต่เป็นว่าข้อมูลของคนคนนี้อยู่ที่ไหนบ้าง\u003C\u002Fp>\u003Cp>ในองค์กรที่โตมาหลายปี คำถามนี้ตอบด้วยประโยคเดียวไม่ได้ ข้อมูลของลูกค้าหนึ่งคนอาจอยู่ในระบบขาย ระบบออกใบแจ้งหนี้ เครื่องมือส่งอีเมลการตลาด ระบบรับเรื่องร้องเรียน ไฟล์สเปรดชีตของทีมงาน และสำเนาที่ถูกลืมในสภาพแวดล้อมทดสอบ บทความนี้เขียนจากมุมของทีมที่ต้องออกแบบระบบให้ตอบคำถามนั้นได้ ไม่ใช่คำแนะนำทางกฎหมาย เราจะเล่าว่าแผนที่ข้อมูลรายบุคคลคืออะไร ควรมีอะไรอยู่ในนั้น และทำไมควรสร้างก่อนที่คำขอฉบับแรกจะมาถึง ส่วนหน้าที่ตามกฎหมายขององค์กรคุณ ควรให้ผู้รับผิดชอบด้านข้อมูลส่วนบุคคลหรือที่ปรึกษากฎหมายเป็นผู้ยืนยัน\u003C\u002Fp>\u003Ch2>กฎใหม่เกี่ยวกับคำขอเข้าถึงข้อมูลว่าด้วยอะไร และเราอ่านถึงไหน\u003C\u002Fh2>\u003Cp>พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) ให้เจ้าของข้อมูลมีสิทธิขอเข้าถึงและขอรับสำเนาข้อมูลส่วนบุคคลของตน สิทธินี้ไม่ใช่เรื่องใหม่ สิ่งที่เปลี่ยนตามรายงานของสำนักงานกฎหมายหลายแห่งคือ คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) ออกประกาศในเดือนกรกฎาคม 2026 กำหนดรายละเอียดวิธีปฏิบัติ เช่น ช่องทางรับคำขอ การตรวจสอบตัวตน กรอบเวลาการตอบ ค่าธรรมเนียม เหตุที่ปฏิเสธได้ และการเก็บบันทึกคำขอ (ดูตัวอย่างรายงานได้ที่ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.tilleke.com\u002Finsights\u002Fthailand-issues-new-rules-on-data-subject-access-requests\u002F\">บทความของ Tilleke & Gibbins\u003C\u002Fa>)\u003C\u002Fp>\u003Cp>เราต้องบอกตรง ๆ ว่าเรายังไม่ได้อ่านตัวประกาศฉบับเต็ม เว็บไซต์ราชกิจจานุเบกษามีด่านตรวจของ Cloudflare ที่เราไม่เปิดผ่าน และหน้าของ PDPC ไม่มีตัวบทให้อ่าน แหล่งรองที่เราเปิดได้ให้รายละเอียดบางข้อไม่ตรงกัน โดยเฉพาะวันมีผลบังคับและระยะเวลาในแต่ละขั้น เราจึงไม่ใส่ตัวเลขกำหนดเวลาใดในบทความนี้ ถ้าองค์กรของคุณต้องการตัวเลขเหล่านั้น ให้อ่านจากตัวประกาศในราชกิจจานุเบกษาโดยตรง หรือถามผู้รับผิดชอบด้านข้อมูลส่วนบุคคลขององค์กร\u003C\u002Fp>\u003Cp>สิ่งที่เราเขียนได้โดยไม่ต้องพึ่งตัวเลขเหล่านั้น คือคำถามด้านระบบที่ทุกองค์กรต้องตอบได้ไม่ว่ากรอบเวลาจะเป็นเท่าใด ข้อมูลของคนคนหนึ่งอยู่ที่ไหนบ้าง ค้นเจอได้อย่างไร และส่งออกได้ในรูปแบบอะไร\u003C\u002Fp>\u003Ch2>ข้อมูลของคนคนเดียว กระจายอยู่ตรงไหนบ้าง\u003C\u002Fh2>\u003Cp>เมื่อเราไล่ดูระบบขององค์กรหนึ่งแบบเป็นรายระบบ ข้อมูลส่วนบุคคลของคนคนหนึ่งมักกระจายอยู่ในที่ต่อไปนี้ ซึ่งบางที่ทีมไม่ได้นึกถึงตอนมีคนถามครั้งแรก\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>ระบบหลักที่ใช้งานจริง\u003C\u002Fstrong> เช่น ระบบสมาชิก ระบบขาย ระบบบัญชี ซึ่งมักมีเจ้าของระบบชัดเจนและค้นข้อมูลได้\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>บริการของผู้ให้บริการภายนอก\u003C\u002Fstrong> เช่น เครื่องมือส่งอีเมล ระบบรับเรื่องลูกค้า เครื่องมือวิเคราะห์พฤติกรรมผู้ใช้ ข้อมูลอยู่ในระบบของเขา แต่ธุรกิจของคุณเป็นผู้เลือกส่งข้อมูลเข้าไป\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>ไฟล์ที่คนในทีมถือเอง\u003C\u002Fstrong> สเปรดชีตรายชื่อลูกค้า ไฟล์ที่ export ไว้ทำรายงาน ไฟล์แนบในอีเมล ซึ่งอยู่นอกการควบคุมของระบบทั้งหมด\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>สำเนาและข้อมูลสำรอง\u003C\u002Fstrong> ฐานข้อมูลในสภาพแวดล้อมทดสอบ และ backup ของระบบเหล่านั้น เรื่องนี้เราเขียนแยกไว้ใน\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Ftest-data-masking-pdpa\">บทความเรื่องข้อมูลจริงกับสภาพแวดล้อมทดสอบ\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>log และข้อมูลจราจร\u003C\u002Fstrong> ที่มีรหัสผู้ใช้ ที่อยู่ IP หรือค่าที่ระบุตัวบุคคลได้โดยตรงหรือทางอ้อม เรื่องการแยกตารางจับคู่รหัสกับตัวบุคคลไว้ในที่ที่สิทธิ์เข้มกว่า เราเขียนไว้ใน\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Flog-retention-audit-trail-thailand\">บทความเรื่องการเก็บ log\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>บางที่ในรายการนี้ ทีมไอทีรู้อยู่แล้ว บางที่รู้อยู่ที่คนอื่น เช่น ฝ่ายการตลาดที่สมัครเครื่องมือใหม่ด้วยบัตรเครดิตของแผนก ปัญหาไม่ได้อยู่ที่ใครทำผิด แต่อยู่ที่ไม่มีใครถือรายการทั้งหมดไว้ในที่เดียว\u003C\u002Fp>\u003Ch2>แผนที่ข้อมูลรายบุคคลคืออะไร\u003C\u002Fh2>\u003Cp>แผนที่ข้อมูลรายบุคคลคือเอกสารหนึ่งชุดที่ตอบได้ว่า ถ้ามีคำขอเกี่ยวกับบุคคลหนึ่ง เราต้องไปค้นที่ไหนบ้าง ค้นด้วยอะไร และดึงข้อมูลออกมาอย่างไร เราไม่ได้มองมันเป็นเอกสารกฎหมาย แต่เป็นคู่มือปฏิบัติงานของทีมไอที เป็นสิ่งที่คนที่ไม่เคยทำงานกับระบบนั้นมาก่อนอ่านแล้วทำตามได้\u003C\u002Fp>\u003Cp>สำหรับแต่ละระบบหรือแหล่งข้อมูล เราบันทึกอย่างน้อยห้าเรื่อง\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>ชื่อระบบ และคนที่เป็นเจ้าของระบบ\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ประเภทข้อมูลส่วนบุคคลที่เก็บอยู่ในนั้น\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ใช้ตัวระบุอะไรในการค้นหา เช่น อีเมล เบอร์โทร รหัสลูกค้า\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ดึงข้อมูลของคนคนหนึ่งออกมาได้อย่างไร และออกมาในรูปแบบไหน\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>ข้อมูลนั้นถูกส่งต่อไปที่ใครหรือระบบไหนต่อ\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>แหล่งรองที่เราอ่านรายงานว่าบันทึกรายการประมวลผลตามมาตรา 39 ของ PDPA เป็นฐานของการตอบคำขอ ซึ่งสอดคล้องกับวิธีที่เราคิด ถ้าองค์กรมีบันทึกรายการประมวลผลอยู่แล้ว ให้ใช้เป็นจุดตั้งต้นของแผนที่ แล้วเติมสิ่งที่งานค้นหาจริงต้องใช้ เช่น วิธีค้น วิธีส่งออก และผู้ที่ทำได้ เรายังไม่ได้อ่านตัวมาตรา 39 โดยตรง จึงไม่ขอสรุปว่าบันทึกฉบับที่องค์กรมีอยู่ครบตามที่กฎหมายกำหนดหรือไม่ ข้อนี้ควรให้ผู้รับผิดชอบด้านข้อมูลส่วนบุคคลตรวจ\u003C\u002Fp>\u003Ch2>ปัญหาที่ซ่อนอยู่คือไม่มีตัวระบุกลาง\u003C\u002Fh2>\u003Cp>ถ้าทุกระบบใช้รหัสลูกค้าตัวเดียวกัน การค้นก็ง่าย แต่ในความเป็นจริง ระบบขายอาจใช้อีเมล ระบบบัญชีใช้เลขประจำตัวผู้เสียภาษี และเครื่องมือการตลาดใช้ที่อยู่อีเมลที่สะกดต่างกันเล็กน้อย บางระบบเก็บเฉพาะเบอร์โทร คนคนเดียวกันจึงมีรหัสหลายแบบ และไม่มีใครจับคู่ให้ครบ\u003C\u002Fp>\u003Cp>วิธีที่เราใช้คือสร้างตารางจับคู่ตัวระบุ ซึ่งบอกว่าบุคคลหนึ่งมีรหัสอะไรในระบบไหนบ้าง ตารางนี้เป็นข้อมูลส่วนบุคคลเสียเอง และเป็นตารางที่ทรงพลัง เพราะจับคู่ตัวตนข้ามระบบได้หมด เราจึงเก็บไว้ในที่ที่สิทธิ์เข้มกว่าระบบทั่วไป มี log ว่าใครเปิดใช้ และไม่ให้ทีมที่ทำงานกับข้อมูลทดสอบหรือ log เห็น ใช้หลักการเดียวกับตารางจับคู่ที่เราเขียนไว้ในบทความเรื่อง log\u003C\u002Fp>\u003Cp>ข้อจำกัดที่ต้องรู้คือ ตารางจับคู่จะครบเท่าที่ระบบมีข้อมูลให้จับ ถ้าลูกค้าสมัครเครื่องมือหนึ่งด้วยอีเมลส่วนตัว และซื้อของอีกช่องทางด้วยอีเมลที่ทำงาน ระบบจะไม่รู้ว่าเป็นคนเดียวกัน การตรวจสอบว่าผู้ขอเป็นเจ้าของข้อมูลชุดนั้นจริงก็เป็นอีกเรื่องหนึ่ง และเป็นหน้าที่ของกระบวนการตรวจตัวตนขององค์กร ไม่ใช่ของตารางนี้\u003C\u002Fp>\u003Ch2>ระบบแบบไหนที่ค้นและส่งออกรายบุคคลได้\u003C\u002Fh2>\u003Cp>เมื่อเราไล่ถามว่าแต่ละระบบ ค้นข้อมูลรายบุคคลได้ไหม คำตอบแบ่งเป็นสามกลุ่มกว้าง ๆ\u003C\u002Fp>\u003Cp>กลุ่มแรกคือระบบที่มีฟังก์ชันค้นและส่งออกอยู่แล้ว ใช้ได้เลยหลังบันทึกวิธีใช้ กลุ่มที่สองคือระบบที่ต้องให้นักพัฒนาหรือผู้ดูแลฐานข้อมูลเขียน query ซึ่งทำได้ แต่ต้องมีคนที่เข้าใจโครงสร้างตารางและมีสิทธิ์เข้าถึง เรามักแนะนำให้เตรียม query หรือสคริปต์ไว้ล่วงหน้า พร้อมทดสอบกับข้อมูลจำลอง กลุ่มที่สามคือระบบที่ผู้ให้บริการภายนอกเป็นเจ้าของ ซึ่งถามได้เพียงว่าเขามีฟังก์ชันส่งออกให้ลูกค้าขององค์กรหรือไม่ และใช้เวลาเท่าใด คำตอบของกลุ่มสามต้องหาจากผู้ให้บริการ ไม่ใช่เดาจากเอกสารขาย\u003C\u002Fp>\u003Cp>รูปแบบของไฟล์ที่ส่งออกก็ควรคิดไว้ก่อน ข้อมูลที่อ่านได้ด้วยโปรแกรมทั่วไป เช่น ไฟล์ตารางหรือไฟล์โครงสร้างมาตรฐาน ช่วยให้ทั้งผู้ขอและทีมอ่านได้ ข้อมูลที่ต้องใช้ซอฟต์แวร์เฉพาะของระบบเก่าจึงจะเปิดได้ เป็นปัญหาที่เราเจอบ่อยตอนที่ระบบเก่าถูกแทนที่ เรื่องนี้โยงกับสิ่งที่เราเขียนไว้ใน\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Fdata-migration-validate-cutover\">บทความเรื่องการย้ายข้อมูลและ cutover\u003C\u002Fa>\u003C\u002Fp>\u003Ch2>ผู้ให้บริการภายนอกในแผนที่ของคุณ\u003C\u002Fh2>\u003Cp>ระบบที่ผู้ให้บริการภายนอกเก็บข้อมูลให้ ยังต้องอยู่ในแผนที่ เพราะข้อมูลที่องค์กรส่งเข้าไปยังเป็นข้อมูลที่องค์กรต้องตอบเมื่อมีคำขอ ไม่ใช่ว่าเมื่อข้อมูลอยู่ในระบบของผู้อื่นแล้ว คำขอจะหายไปเอง เรื่องบทบาทตามกฎหมายของผู้ให้บริการแต่ละราย เป็นสิ่งที่ผู้รับผิดชอบด้านข้อมูลส่วนบุคคลต้องประเมินเป็นรายกรณี เราไม่ฟันธงแทน\u003C\u002Fp>\u003Cp>สิ่งที่ทีมไอทีทำได้คือ ถามผู้ให้บริการสามเรื่องก่อนเซ็นสัญญาหรือก่อนต่ออายุ ว่าส่งออกข้อมูลรายบุคคลได้ไหม ได้ในรูปแบบอะไร และเมื่อสัญญาสิ้นสุดแล้วข้อมูลอยู่ที่ใคร เราเขียนแนวคิดทำนองนี้ไว้ใน\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Ftor-conditions-for-a-maintainable-system\">บทความเรื่องเงื่อนไขใน TOR\u003C\u002Fa> และเรื่องผู้ให้บริการที่อาจหายไปในปีที่สามอยู่ใน\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdev.tech\u002Fblogs\u002Fvendor-continuity-due-diligence\">บทความเรื่องความเสี่ยงที่ vendor จะหายไป\u003C\u002Fa>\u003C\u002Fp>\u003Ch2>เมื่อผลการค้นมีข้อมูลของคนอื่นปนมาด้วย\u003C\u002Fh2>\u003Cp>การค้นด้วยชื่อหรืออีเมลมักได้มากกว่าที่ต้องการ ไฟล์เดียวอาจมีข้อมูลของหลายคน ข้อความในระบบรับเรื่องอาจกล่าวถึงลูกค้าสองรายในเธรดเดียว แหล่งรองรายงานว่าประกาศฉบับใหม่ระบุกรณีที่ปฏิเสธหรือจำกัดการให้ข้อมูลได้ เมื่อการให้ข้อมูลกระทบสิทธิของบุคคลอื่น แต่เรายังไม่ได้อ่านตัวบท จึงไม่ขอบอกว่าต้องทำอย่างไรในแต่ละกรณี\u003C\u002Fp>\u003Cp>ในมุมระบบ เราแนะนำให้ผลการค้นถูกตรวจโดยคนก่อนส่งออกเสมอ และให้ระบบหรือสคริปต์ที่ดึงข้อมูลแยกรายการที่เป็นของบุคคลนั้นโดยตรงออกจากรายการที่มีบุคคลอื่นปนอยู่ เพื่อให้คนตัดสินใจได้ง่ายขึ้น การตัดสินใจว่าจะเปิดเผยอะไรเป็นของผู้รับผิดชอบด้านข้อมูลส่วนบุคคลและฝ่ายกฎหมาย ไม่ใช่ของสคริปต์\u003C\u002Fp>\u003Ch2>ข้อจำกัดที่ต้องบอกตรง ๆ\u003C\u002Fh2>\u003Cp>ถ้าองค์กรของคุณมีระบบข้อมูลส่วนบุคคลเพียงระบบเดียว คนดูแลคนเดียว และยังไม่เคยมีใครขอข้อมูลเลย แผนที่ข้อมูลเต็มรูปแบบอาจเกินความจำเป็น กระดาษหนึ่งแผ่นที่เขียนว่าข้อมูลอยู่ที่ไหน ใครเข้าถึงได้ และดึงออกมาอย่างไร ก็พอเป็นจุดเริ่มต้น เพราะเอกสารที่ใหญ่เกินงานจริงจะกลายเป็นเอกสารที่ไม่มีใครอัปเดต และเอกสารที่ล้าสมัยอันตรายกว่าไม่มีเอกสาร เพราะคนเชื่อว่ามันถูก\u003C\u002Fp>\u003Cp>อีกข้อที่เราอยากบอกคือ แผนที่ข้อมูลไม่ได้พิสูจน์ว่าการค้นครบถ้วน ข้อมูลที่อยู่ในไฟล์ที่ไม่มีใครบันทึก ในแชทส่วนตัว หรือในกระดาษ จะไม่อยู่ในแผนที่ สิ่งที่แผนที่ทำได้คือทำให้ส่วนที่รู้แล้วค้นได้เป็นระบบ และทำให้ส่วนที่ยังไม่รู้ถูกมองเห็นเป็นช่องว่างที่ต้องปิด ไม่ใช่ความเสี่ยงที่ซ่อนอยู่\u003C\u002Fp>\u003Ch2>ข้อโต้แย้งที่ได้ยินบ่อย\u003C\u002Fh2>\u003Cp>ข้อโต้แย้งที่ได้ยินบ่อยที่สุดคือ ยังไม่เคยมีใครขอข้อมูลเลย ทำไมต้องลงแรงเตรียม คำถามนี้ถูกต้อง และถ้าไม่เคยมีคำขอจริง ๆ ลำดับความสำคัญของเรื่องนี้ก็ไม่ควรสูงกว่าเรื่องที่ระบบเจอปัญหาอยู่ทุกสัปดาห์ แต่แผนที่ข้อมูลไม่ได้ใช้ตอบคำขอเข้าถึงอย่างเดียว ถ้ามีคนขอให้ลบข้อมูล หรือเกิดเหตุข้อมูลรั่ว คำถามแรกก็เป็นคำถามเดิมว่าข้อมูลอยู่ที่ไหนบ้าง\u003C\u002Fp>\u003Cp>ข้อโต้แย้งอีกข้อคือ ทีมกฎหมายหรือผู้รับผิดชอบด้านข้อมูลส่วนบุคคลจัดการเรื่องนี้อยู่แล้ว ซึ่งจริง และเป็นสิ่งที่ควรเป็น แต่ผู้รับผิดชอบด้านนี้ตัดสินใจได้เฉพาะเรื่องที่ทีมไอทีให้ข้อมูลมาตรง แผนที่ข้อมูลคือสิ่งที่ทีมไอทีส่งให้เขา ทีมไอทีรู้ว่าระบบทำอะไรได้จริง ส่วนผู้รับผิดชอบด้านข้อมูลรู้ว่ากฎหมายต้องการอะไร สองฝั่งต้องมีเอกสารชุดเดียวกันวางบนโต๊ะ\u003C\u002Fp>\u003Cdiv data-type=\"horizontalRule\">\u003Chr>\u003C\u002Fdiv>\u003Ch2>จะเริ่มตรงไหน\u003C\u002Fh2>\u003Col>\u003Cli>\u003Cp>\u003Cstrong>ไล่รายการระบบที่เก็บข้อมูลส่วนบุคคล\u003C\u002Fstrong> รวมบริการภายนอก ไฟล์ที่คนถือเอง และสำเนาในสภาพแวดล้อมทดสอบ ถามแต่ละแผนกว่าใช้เครื่องมืออะไรอยู่ อย่าถามแค่ทีมไอที\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>ระบุเจ้าของของแต่ละแหล่ง\u003C\u002Fstrong> เป็นรายชื่อคน ไม่ใช่ชื่อแผนก\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>ทดลองค้นข้อมูลของคนหนึ่งคนในทุกระบบ\u003C\u002Fstrong> ใช้บุคคลสมมติหรือเจ้าหน้าที่ที่ยินยอม แล้วจับเวลาและจดว่าติดตรงไหน\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>เขียนวิธีค้นและส่งออกของแต่ละระบบ\u003C\u002Fstrong> ให้คนที่ไม่เคยทำมาก่อนทำตามได้ และเก็บ query หรือสคริปต์ไว้ในที่ที่ทีมเข้าถึงได้\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>ส่งแผนที่ให้ผู้รับผิดชอบด้านข้อมูลส่วนบุคคลตรวจ\u003C\u002Fstrong> พร้อมรายการช่องว่างที่ยังปิดไม่ได้ และกำหนดวันทบทวนซ้ำ\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Fol>\u003Ch2>สรุป\u003C\u002Fh2>\u003Cp>ถ้าจะหยิบไปใช้อย่างเดียวจากบทความนี้ ให้ลองค้นข้อมูลของคนหนึ่งคนในทุกระบบที่องค์กรมี แล้วจดว่าติดตรงไหน รายการที่ติดคือสิ่งที่ต้องแก้ก่อนคำขอฉบับแรกจะมาถึง\u003C\u002Fp>\u003Cp>หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล contact@superdev.tech สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส\u003C\u002Fp>","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fpbc_2128795511\u002F1i6h2b0k3konkxq\u002Fcover_cover_gdmm6i1nt0.webp","28 ตุลาคม 2569","2026-10-28 09:03:15.250Z",114,"Enterprise","enterprise","pdpc-access-request-data-map-per-person","\u002Fblogs\u002Fpdpc-access-request-data-map-per-person",2,false,0,"",[47,48,49,50,51],"สิทธิขอเข้าถึงข้อมูลส่วนบุคคล","คำขอเข้าถึงข้อมูลส่วนบุคคล","ขอรับสำเนาข้อมูลส่วนบุคคล","data mapping","PDPA"]