PDPA มองพรบ. คุ้มครองข้อมูลส่วนบุคคลกับ KBTG

หลังจากที่มีประกาศออกมาว่าทางคณะรัฐมนตรี (ครม.) มีการเลื่อนการบังคับใช้พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล หรือ PDPA (Personal Data Protection Act) ออกไปอีก 1 ปี เป็นปี 2022 แทน หลายบริษัทน่าจะแอบโล่งอกไปตามๆ กันที่ได้ต่อเวลาในการเตรียมพร้อม แต่นั่นก็ไม่ได้หมายความว่าควรชะล่าใจ ผลัดวันประกันพรุ่งไปทำคราหลังแต่อย่างใด เพราะกฎหมายฉบับนี้มีความสำคัญมากๆ ยิ่งในยุคที่ Data เป็นใหญ่เช่นปัจจุบันด้วยแล้ว เพื่อที่จะทำความเข้าใจ PDPA อย่างถ่องแท้ รวมถึงสาเหตุว่าทำไมทุกบริษัท ไม่ว่าจะเล็กหรือใหญ่ ทำธุรกิจในรูปแบบไหน ก็ต้องปฏิบัติตามกฎนั้น พี่มล Senior Enterprise Architect และเลขาคณะ DPO Committee (Data Protection Officer Committee) ของ KBTG จะมาสรุปให้ฟังกันค่ะ เริ่มด้วยคำถามสุดคลาสสิกนี้…

PDPA คืออะไร?

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

ข้อดีของ PDPA

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

ทาง KBTG ได้เริ่มดำเนินการในเรื่องของ PDPA อย่างไรแล้วบ้าง?

ทาง KBank และ K-Group รวมถึง KBTG ได้มีการตั้งหน่วยงานจริงจังตั้งแต่ช่วงกลางปี 2019 เราเริ่มจากการตีความกฎหมาย หา Best Practice จากเมืองนอกมาศึกษา จากนั้น KBank ร่วมด้วยการสนับสนุนทางด้าน IT Development จาก KBTG ก็คลอด PDPA Consent ในเดือนเมษายน ปี 2020 ทำให้เรากลายเป็นธนาคารแห่งแรกที่ทำเรื่อง Consent อย่างถูกต้องตามกติกา และทำเป็นแบบ Freely Given จริงๆ นำมาซึ่งคำชมมากมายจากแวดวงการเงินและเป็นกำลังใจที่ดีกับทีมทำงานอย่างมาก

หลักการ Freely Given

• บนหน้าจอที่ลูกค้าเห็นจะต้องเป็นช่องให้เลือก “ยินยอม” หรือ “ไม่ยินยอม” แบบไม่มี Pre-tick แสดงเป็นค่า Default
• ต้องสะดวกทั้งในการให้และถอน Consent ควรอยู่บนช่องทางเดียวกัน และสามารถถอนได้ทุกเวลาที่ต้องการ แนวทางของ KBank คือพัฒนา Consent ให้เป็น Self-Service ที่ลูกค้าให้สามารถขอและถอนได้อย่างสะดวกบน K+

หลังจากที่ KBTG ได้ช่วยรองรับ KBank มาระดับหนึ่งจนถึงช่วงปี 2020 ทีมคณะทำงานก็มีความรู้มากพอที่จะพา KBTG ให้ Compile PDPA เราเริ่มจากการพิจารณาบทบาทของคนใน KBTG ก่อนว่าบทบาทไหนเป็นผู้ควบคุมข้อมูล (Controller) หรือผู้ประมวลผลข้อมูล (Processor) ซึ่งเราก็พบกว่าเรามีทั้ง 2 บทบาท แต่ส่วนใหญ่กว่า 90% เราจะรับหน้าที่เป็นผู้ประมวลผล (Data Controller) เป็นงาน IT Service เพื่อให้ธนาคารสามารถเก็บรวบรวม ใช้ เปิดเผยข้อมูลอย่างถูกต้องตามกฎหมาย ซึ่ง Tasks ต่างๆ เกี่ยวกับ PDPA จะเทไปทางธนาคาร ในขณะที่อีกไม่ถึง 5% จะรับหน้าที่เป็นผู้ควบคุมข้อมูลส่วนบุคคล (Data Controller) กรณีนี้ก็ไม่ต่างอะไรกับที่ทางธนาคารทำ คือ เราต้อง Implement PDPA Item ต่างๆให้ครบตามที่ PDPA กำหนดเช่นกัน ยกตัวอย่าง Items สำคัญๆ อันได้แก่

• แต่งตั้ง Data Protection Officer (DPO) และตั้งคณะทำงานเพื่อเป็นหน่วยงานหลักที่ทำงานด้านนี้
• มีการประกาศนโยบายการคุ้มครองข้อมูลส่วนบุคคล (Privacy Policy) ให้ทั้งคนนอกและคนในรับรู้ว่าองค์กรจะเก็บ รักษา ใช้ข้อมูลที่ผู้ใช้ให้ไว้อย่างไร มีการเปิดเผยให้ใครบ้าง และกิจกรรมใดที่เราใช้ฐาน Legitimate Interest ในการใช้และประมวลผลข้อมูล เช่น การแลกบัตรหน้าประตู
• จัดทำนโยบายการดูแลข้อมูลส่วนบุคคล เป็นกฎระเบียบให้คนในองค์กรปฏิบัติงานอย่างถูกต้อง
• เก็บบันทึกประวัติการประมวลผลข้อมูลที่เรียกว่า RoPA (The Record of Processing Activities)
• ทำ Consent ขอเก็บข้อมูล Sensitive บางประเภทที่ต้องมีการลงลายเซ็นต์ เช่น ประวัติรักษาโรคของพนักงานเพื่อยื่นเคลมประกันแทนพนักงาน
• เปิดคอร์สให้ความรู้ PDPA ให้แก่บุคคลากรทุกคนใน KBTG โดยออกแบบคอร์สพิเศษที่เน้นเรื่องการพัฒนาระบบให้สอดคล้องกับ PDPA ต้องทำอย่างไรบ้าง

ทำไมต้องทำ RoPA?

RoPA เป็นเหมือนไบเบิลที่บอกว่าฝ่ายงานไหนในองค์กรทำอะไร ทำด้วยวัตถุประสงค์อะไร และอยู่บนฐานกฎหมายข้อไหนที่อนุญาตให้ทำ จุดประสงค์หลักเพื่อให้องค์กรสามารถเช็ค Impact ได้อย่างรวดเร็วตามที่กฎหมาย PDPA กำหนดคือ 72 ชั่วโมง เมื่อมีเหตุข้อมูลรั่วไหล (Data Breach Incident) งาน RoPA ของ KBTG ค่อนข้างท้าทายมากเนื่องจากเรามีหน่วยงานนวัตกรรมที่ค่อนข้างอิสระและนำส่งงานอย่างรวดเร็วแบบสตาร์ทอัพ ทั้งยังมีงานแนว Machine Learning Development ทำให้การเก็บบันทึก RoPA ต้องทำกันแบบ Proactive คือ เมื่อเกิดโครงการหรือ Scenario ใหม่ต้องมาอัพเดตทันที ไม่สามารถรอรอบ Annual Review ได้

ข้อดีอีกข้อของการบันทึก RoPA แบบนี้ คือเราสามารถใช้ RoPA เป็นเสมือน Checklist ไว้ให้ชาว Data Scientists ได้ทบทวนตัวเองว่า Scenario ที่ทำอยู่นั้นใช้ข้อมูลส่วนบุคคลหรือไม่ ที่มาขอข้อมูลถูกกฎหมายหรือไม่ สามารถวิเคราะห์ได้ฐานอะไร และ ใครเป็น Controller ของงานนี้ เป็นต้น ยิ่งข้อมูล RoPA ยิ่งละเอียด ยิ่งลดความผิดพลาดในการละเมิดกฎหมาย PDPA

การบันทึก RoPA

• RoPA as a Controller ควรพิจารณา Activity ว่ามีฐานกำหมายอะไรรองรับได้ และ T&C ครอบคลุมรึยัง ถ้ายังจะไปด้วย Consent หรือ Legitimate Interest หรือไม่เก็บข้อมูลเลย นอกจากนี้ควรมีความสอดคล้องกันไปจนถีง Subject Right ที่ลูกค้าสามารถขอให้ KBTG ทำให้ในแต่ละ Service ที่ให้บริการ
• RoPA as a Processor ควรมีการระบุ Controller ผู้สั่งงาน Processor และเก็บหลักฐานการสั่งเป็นลายลักษณ์อักษร เช่น สัญญา MOU เอกสาร Requirement ที่มี Sign-off โดย Controller

ความท้าทายที่มากับ PDPA…

ตามหลักการ PDPA แล้ว ถ้าเราอยากวิเคราะห์ข้อมูล PII (Personally Identifiable Information) เราควรขออนุญาตและได้รับอนุญาตจากเจ้าของข้อมูลหรือลูกค้าก่อนที่จะเก็บ ใช้ เปิดเผย ทำลายข้อมูล โดยหลักการขออนุญาตนั้นสามารถทำได้โดยระบุลงใน Term & Condition หรือขอ Consent จากลูกค้า หรือแจ้งเป็น Legitimate Interest โดยเฉพาะกิจกรรมการวิเคราะห์ข้อมูลเป็นกิจกรรมที่ต้องมีการควบคุมอย่างระมัดระวัง เพราะถ้าอ่านตามกฎหมายแล้วเราควรขอ Consent และเลือกเฉพาะที่ได้รับอนุญาตเท่านั้นในการนำมาวิเคราะห์ นั่นหมายความว่า ถ้าเรามีข้อมูลข้อมูลส่วนบุคคล 100% เราขอ consent ได้ 50% แสดงว่าเราสามารถวิเคราะห์บนข้อมูลส่วนบุคคลนั้นได้แค่ 50% ซึ่งข้อมูลที่หายไปอาจส่งผลต่อการค่าความแม่นยำ (Accuracy) ของการวิเคราะห์ ดังนั้นธนาคารจึงทำข้อมูลให้เป็นข้อมูลนิรนาม (Anonymous Data) ก่อนนำไปใช้

ทาง KBTG ได้เลือกใช้ Cloud Based Technology มาทำให้เป็น Closed Environment for Analytical Purpose โดยด้านในแพลตฟอร์มมีฐานข้อมูลที่เก็บข้อมูลนิรนาม (Anonymous Data) มี Build-in Tools เพื่องาน Analytics ต่างๆ อย่าง Model Development Tools, Business Intelligent Tools และ Data Exploration Tools จากนั้นซีลแพลตฟอร์มให้สามารถเข้าไปใช้งานได้ผ่าน VDI (Virtual Desktop Interface) แต่ไม่สามารถ Export/Import ข้อมูลออกนอก Environment ได้

ข้อดีของการออกแบบให้เป็น Environment เช่นนี้

• แม้ว่า Cloud จะเป็น Environment ที่เป็นของ Provider และอาจจะมีความเสี่ยงกว่าเมื่อเทียบกับ On premise ที่มี Physical Protection และ Access Control ต่างๆ แต่ถ้าหากเราเลือกมาใช้โฮสเฉพาะข้อมูลนิรนามที่ไม่รู้จักตัวบุคคลก็ถือว่าความเสี่ยงนั้นลดลงมาอยู่ในระดับที่พอจะรับได้ นั่นคือหากโดนแฮกออกไป ข้อมูลพวกนี้ไม่รู้ว่าเป็นข้อมูลของใครอยู่ดี ก็จะไม่มีเจ้าของข้อมูลมาฟ้องร้องเรื่อง Data Breach กับเราได้ (แต่ก็ยังควรป้องกันอยู่ดี เพราะถ้าข้อมูลจำนวนมากรั่วไหลออกไป ในมุมภาพรวม Port ของธนาคารก็เสียหายอยู่ดี)
• การทำการวิเคราะห์มักต้องใช้ Resource ของเครื่องไม่ว่าจะเป็นโน้ตบุ๊คหรือเซิร์ฟเวอร์มหาศาล การย้าย Activity นี้ขึ้น Cloud เป็นการกำจัดลิมิตฮาร์ตแวร์และเป็นประโยชน์ต่อ Analyst และ Data Scientist ในแง่ Productivity
• การที่เราออกแบบให้มี VDI เป็นตัวกลางนั้นเนื่องมาจากว่าเราไม่ต้องการให้เกิดเคสที่คนสามารถ Import ข้อมูลส่วนบุคคลเข้าระบบ หรือ Export ข้อมูลออกนอกระบบ แล้วทำการชน (Mapping) ข้อมูลนิรนามกลับมาเป็นข้อมูลส่วนบุคคลได้ (PII Data) ถ้าเราสามารถชนกลับมาได้ เราก็จะกลับไปอยู่ Under PDPA ทันที

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

• ทีม Data Governance และ ทีม Risk ที่ออก Policy & Guideline ต่างๆ เพื่อบังคับให้เกิดการปฎิบัติจริง สื่อความเพื่อสร้างความเข้าใจต่อผู้ใช้
• ผู้ใช้เองต้องเข้าใจในตัวกฎหมาย PDPA ฉบับนี้ และเข้าใจความจำเป็นของการทำโครงการ เขาจึงจะเปิดใจรับสิ่งใหม่ เรียนรู้เครื่องมือใหม่ ปรับพฤติกรรม ยอมถอย ลดความสะดวกสบายบางอย่างการเพิ่มขั้นตอนการทำงาน
• ทีม KBTG ทาง IT เองก็ต้องเข้าไปศึกษากระบวนการทำงานปัจจุบันของผู้ใช้ จากนั้นนำมาทำโซลูชันและหาเครื่องมือต่างๆ มารองรับการทำงาน ให้ผู้ใช้งานปรับตัวน้อยที่สุด

ทำไมทุกบริษัทควรเร่งปฏิบัติตาม PDPA?

แม้จะมีประกาศเลื่อนการบังคับใช้ PDPA ออกไปเป็นปีหน้า KBank และ K-Group ยังยืนหยัดในการ Comply ตามกำหนดการเดิม ส่วนหนึ่งเป็นเพราะ 1 ปีที่เราทำนำหน้าคนอื่นไปนั้น เรามองว่าน่าจะเป็นช่วงเวลาที่ดีที่ให้เราซักซ้อม เหมือนเป็นการ Dry Run กระบวนการทำงานหรือระบบต่างๆ ที่เราได้เตรียมไปแล้ว เราอาจจะได้เห็นช่องโหว่ของปัญหาและได้แก้ปัญหาก่อนคนอื่น ซึ่งพี่ก็ขอเชิญชวนบริษัทและองค์กรต่างมาเริ่มศึกษาและเปลี่ยนแปลงให้เป็นไปตามข้อกำหนดของ PDPA กันตั้งแต่ตอนนี้

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

เริ่มต้นก้าวแรก… อย่างไรดี

สิ่งแรกที่ควรทำคือศึกษาข้อบังคับใน PDPA จากนั้นถ้านึกไม่ออกว่าต้องทำอะไรบ้างถึงจะ Comply ให้เริ่มจากสำรวจบริษัทของคุณเองโดยการทำ RoPA ก่อน Activity ใน RoPA จะเป็นเสมือน Requirement ตั้งต้นให้เกิดงานอื่นๆ ต่อไป ถ้าถามว่าควรเริ่มต้นจากตรงไหน ให้ดู Activity ของแผนก HR ก่อนเลย เพราะทุกบริษัทมี HR ให้ลองทำจากตรงนี้เพื่อหาประสบการณ์ จากประสบการณ์ที่ผ่านมา พบว่า Activity ของ HR มีคาแรกเตอร์แตกต่างกันพอสมควรที่สามารถใช้หาประสบการณ์ก่อน Roll-out ไปที่ทีมอื่นๆ เช่น

• การดำเนินการตามสัญญาจ้างต่างๆ มีฐานกฎหมายอยู่เกือบหมด
• การจัดอบรมพนักงานที่ต้องมีการอัดวิดีโอที่เป็น Biometric Data ต้องขออนุญาตผู้สอนหรือผู้อบรมหรือไม่
• บางบริษัทมีการสแกนนิ้ว ต้องทำอย่างไร เก็บ Biometric Data นี้อย่างถูกต้องต้องทำไง เลือกใช้ฐาน Legitimate Interest เหมาะสมหรือไม่
• การนำข้อมูลไปส่งรักษาพยาบาลไปเบิกประกันหมู่ก็เกี่ยวข้องกับสองเรื่อง หนึ่งคือนับเป็นการแชร์ Data ไปให้องค์กรอื่น และอีกหนึ่งคือการเก็บ Sensitive Data อย่างข้อมูลสุขภาพจำเป็นต้องมี Consent

แค่ฝ่ายเดียวก็มีเรื่องสนุกให้ทำมากมายแล้ว ถ้าไม่เริ่มตั้งแต่วันนี้ ปีหน้าเห็นทีจะทำไม่ทัน ไหนๆ เราก็ได้ Grace Period เพิ่มอีกหนึ่งปี ก็ลุกขึ้นมาจัดการกันตั้งแต่วันนี้กันเลยดีกว่า จะได้ไม่รีบร้อนตอนที่บังคับใช้จริงๆ ค่ะ

สำหรับชาวเทคคนไหนที่สนใจเรื่องราวดีๆแบบนี้ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ ของ KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech