PDPA ข้อมูลรั่วไหลจากเว็บที่ไม่ได้อัปเดต: แจ้งภายใน 72 ชั่วโมง และต้องมีหลักฐานอะไรไว้ก่อน

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

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

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

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

ลองตอบห้าคำถามนี้ดูก่อน ใช้เวลาไม่ถึงสิบนาที

ไม่ต้องเปิดโค้ดครับ แค่ถามตัวเองหรือถามทีมที่ดูแลเว็บ แล้วนับว่าตอบได้ทันทีพร้อมหลักฐานกี่ข้อ

• เว็บของเราใช้ระบบอะไร รุ่นไหน และอัปเดตครั้งล่าสุดเมื่อไหร่ ตอบเป็นวันที่ได้ไหม

• ตอนนี้ใครบ้างที่ถือรหัสผ่านระดับแอดมิน รวมถึงฟรีแลนซ์เก่าหรือพนักงานที่ลาออกไปแล้ว

• ข้อมูลที่ลูกค้ากรอกผ่านฟอร์มไปเก็บไว้ที่ไหน และใครเปิดดูได้บ้าง

• สำรองข้อมูลครั้งล่าสุดเมื่อไหร่ และเคยลองกู้คืนจริงสักครั้งหรือยัง

• ถ้าทีมดูแลเว็บเจอความผิดปกติตอนตีสองคืนวันศุกร์ เขาต้องโทรหาใครในองค์กร

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

กฎหมายเขียนเรื่องนี้ไว้ตรงไหน

มาตรา 37(1) พูดถึงการทบทวนเมื่อเทคโนโลยีเปลี่ยน

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

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

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

72 ชั่วโมงเริ่มนับตอนไหน

มาตรา 37(4) ของกฎหมายฉบับเดียวกันให้แจ้งเหตุการละเมิดข้อมูลส่วนบุคคลแก่สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล หรือ สคส. โดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ทราบเหตุ เท่าที่จะสามารถทำได้ เว้นแต่เหตุนั้นไม่มีความเสี่ยงที่จะกระทบสิทธิและเสรีภาพของบุคคล และถ้าความเสี่ยงสูง ต้องแจ้งเจ้าของข้อมูลพร้อมแนวทางเยียวยาโดยไม่ชักช้าด้วย

วิธีแจ้งเขียนไว้ละเอียดในประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565 ซึ่งลงราชกิจจานุเบกษาเมื่อ 15 ธันวาคม 2565 ข้อ 6 ของประกาศกำหนดให้การแจ้ง สคส. มีสาระสำคัญสี่เรื่องเท่าที่จะทำได้ คือ ลักษณะและประเภทของการละเมิด ซึ่งอาจบอกจำนวนเจ้าของข้อมูลหรือจำนวนรายการที่เกี่ยวข้อง ชื่อและช่องทางติดต่อของเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลหรือผู้ประสานงาน ผลกระทบที่อาจเกิดขึ้น และมาตรการที่ใช้หรือจะใช้เพื่อป้องกัน ระงับ แก้ไข หรือเยียวยาความเสียหาย

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

ทีมดูแลเว็บจากข้างนอกก็มีนาฬิกาของตัวเอง

องค์กรจำนวนมากจ้างบริษัทหรือฟรีแลนซ์ดูแลเว็บ ในภาษากฎหมายคนกลุ่มนี้คือผู้ประมวลผลข้อมูลส่วนบุคคล มาตรา 40(2) ให้ผู้ประมวลผลต้องมีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสมเช่นกัน และต้องแจ้งให้ผู้ควบคุมข้อมูลทราบเมื่อเกิดเหตุ ส่วนประกาศปี 2565 ข้อ 8 เขียนไว้ชัดว่าข้อตกลงหรือสัญญาระหว่างสองฝ่ายต้องระบุให้ผู้ประมวลผลแจ้งเหตุแก่องค์กรโดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ผู้ประมวลผลทราบเหตุ

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

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

ทำไมเว็บที่ไม่ได้อัปเดตถึงเป็นประตูบานแรกที่ถูกลอง

รายงาน Data Breach Investigations Report ปี 2026 ของ Verizon ซึ่งเก็บเหตุการณ์ทั่วโลกช่วง 1 พฤศจิกายน 2024 ถึง 31 ตุลาคม 2025 พบว่า 31% ของเหตุข้อมูลรั่วเริ่มต้นจากช่องโหว่ของซอฟต์แวร์ และช่องโหว่ขึ้นมาเป็นทางเข้าอันดับหนึ่งของผู้โจมตี แซงการใช้รหัสผ่านที่ถูกขโมยไปแล้ว

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

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

คนที่อยากรู้ว่าเว็บของตัวเองมีสัญญาณเตือนด้านอื่นอะไรอีก ทั้งเรื่องความเร็ว ระบบล่ม และการสำรองข้อมูล ผมรวบรวมไว้ในบทความบริการ Maintenance & Support สำคัญอย่างไรต่อเว็บไซต์ธุรกิจแล้วครับ

เคสจริงที่ สคส. สั่งปรับ ดูที่อะไรบ้าง

เมื่อ 21 สิงหาคม 2567 กระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคมแถลงว่าคณะกรรมการผู้เชี่ยวชาญ คณะที่ 2 มีคำสั่งปรับทางปกครองบริษัทเอกชนรายใหญ่ที่ขายสินค้าออนไลน์ รวม 7 ล้านบาท หลังข้อมูลส่วนบุคคลของลูกค้ามากกว่า 1 แสนรายรั่วไหลไปถึงแก๊งคอลเซ็นเตอร์ ข่าวของกระทรวงระบุว่าเป็นคำสั่งปรับทางปกครองฉบับแรกกับบริษัทเอกชนรายใหญ่ของคณะกรรมการชุดนี้

ส่วนที่น่าสนใจสำหรับคนดูแลเว็บคือเหตุผลในคำสั่งครับ ข่าวแจกแจงความผิดไว้สามเรื่อง คือ บริษัทไม่มีเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลตามมาตรา 41 ไม่มีมาตรการรักษาความปลอดภัยที่เหมาะสมตามมาตรา 37(1) และแจ้งเหตุให้ สคส. ล่าช้าตามมาตรา 37(4)

สองในสามเรื่องนั้นคือมาตรา 37 ที่เราคุยกันมาตั้งแต่ต้น และทั้งสองเรื่องเป็นของที่ต้องเตรียมไว้ก่อนเกิดเหตุ

นอกจากค่าปรับ คำสั่งยังให้บริษัทปรับปรุงมาตรการรักษาความปลอดภัย อบรมพนักงาน เพิ่มมาตรการให้ทันกับเทคโนโลยีที่เปลี่ยนไป และแจ้ง สคส. ถึงมาตรการแก้ไขภายใน 7 วันนับแต่ได้รับคำสั่ง ถ้าอ่านรายการนี้ดีๆ จะเห็นว่าคือสิ่งที่องค์กรทำเองได้ตั้งแต่วันนี้ โดยไม่ต้องรอให้มีคำสั่ง

ใครอยากดูภาพรวมของโทษปรับแต่ละมาตรา ผมสรุปไว้ในบทความPDPA กับเว็บไซต์ธุรกิจ: ฟอร์มติดต่อของคุณขอความยินยอมถูกต้องหรือยังครับ เฉพาะมาตรา 37 นั้น ตัวบทมาตรา 83 กำหนดโทษปรับทางปกครองไว้ไม่เกินสามล้านบาท

เว็บเราแค่มีฟอร์มติดต่อ จะมีอะไรให้ขโมย

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

ประกาศปี 2565 ข้อ 9 เปิดช่องให้องค์กรยกข้อยกเว้นการแจ้ง สคส. ได้ ถ้าพิสูจน์ได้ว่าเหตุนั้นไม่มีความเสี่ยงต่อสิทธิและเสรีภาพของบุคคล เช่น ข้อมูลที่รั่วระบุตัวคนไม่ได้ หรือข้อมูลอยู่ในสภาพที่ใช้งานไม่ได้เพราะมีมาตรการทางเทคโนโลยีที่เพียงพอ ส่วนข้อ 7 ให้ขอยกเว้นความผิดจากการแจ้งช้ากว่า 72 ชั่วโมงได้ ถ้ามีเหตุจำเป็นที่หลีกเลี่ยงไม่ได้ โดยต้องชี้แจงเหตุผลกับ สคส. และต้องแจ้งไม่เกิน 15 วันนับแต่ทราบเหตุ

พูดง่ายๆ คือกฎหมายเผื่อที่ไว้ให้องค์กรที่ทำงานมาอย่างรอบคอบ

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

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

หลักฐานที่ย้อนกลับไปสร้างทีหลังไม่ได้

กลับไปที่ประตูออฟฟิศอีกครั้งครับ ถ้าคุณเปลี่ยนกุญแจวันนี้ ประตูก็ปลอดภัยขึ้นตั้งแต่วันนี้ แต่บันทึกว่าเคยตรวจประตูเมื่อเดือนที่แล้ว ไม่มีทางเขียนย้อนหลังให้เป็นของจริงได้

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

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

แฟ้มขั้นต่ำที่เว็บองค์กรควรมี

ไม่ต้องเริ่มจากระบบใหญ่ครับ เริ่มจากแฟ้มเดียวที่ตอบห้าคำถามตอนต้นบทความได้ จากที่ผมเห็นในงานดูแลระบบ อย่างน้อยควรมีหกเรื่องนี้

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

บันทึกการอัปเดตและเหตุผล ถ้ามีรุ่นแก้ไขออกมาแล้วแต่ยังไม่ติดตั้ง ให้จดว่าเพราะอะไรและจะติดตั้งเมื่อไหร่ บางครั้งเหตุผลฟังขึ้นจริง เช่น ต้องทดสอบก่อนเพราะปลั๊กอินตัวอื่นอาจพัง บันทึกแบบนี้คือร่องรอยของการทบทวนมาตรการตามมาตรา 37(1) ที่จับต้องได้ที่สุด

รายชื่อบัญชีที่มีสิทธิ์สูง ทั้งบัญชีแอดมินของเว็บ บัญชีโฮสติ้ง และบัญชีโดเมน ทบทวนทุกครั้งที่มีคนเข้าหรือออกจากทีม

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

บันทึกการเข้าถึงระบบหลังบ้าน ใครเข้าดูข้อมูลลูกค้าเมื่อไหร่ เก็บไว้ในที่ที่แยกจากตัวเว็บ คนที่เจาะเว็บเข้ามาจะได้ลบร่องรอยได้ไม่ง่าย

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

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

เริ่มในเดือนนี้ได้เลย

ห้าขั้นตอนนี้ทำให้จบได้ภายในราวหนึ่งเดือน ไม่ต้องใช้งบใหม่ ใช้แค่เวลาของคนในองค์กรกับทีมดูแลเว็บที่มีอยู่แล้ว

1. ขอรายการซอฟต์แวร์และเวอร์ชันทั้งหมดจากทีมดูแลเว็บ พร้อมวันที่อัปเดตล่าสุดของแต่ละตัว

2. ไล่รายชื่อบัญชีแอดมิน ปิดบัญชีของคนที่ไม่ได้ทำงานกับเว็บแล้ว และจดวันที่ปิดไว้

3. ขอให้ทีมดูแลลองกู้ข้อมูลจาก backup ล่าสุดไปที่เครื่องทดสอบ แล้วจดว่าใช้เวลาเท่าไหร่

4. เปิดสัญญาดูแลเว็บ ดูว่ามีข้อแจ้งเหตุภายใน 72 ชั่วโมงตามประกาศปี 2565 ข้อ 8 หรือยัง ถ้ายังไม่มี ชวนผู้รับจ้างคุยเพื่อเพิ่มเข้าไป

5. เขียนผังติดต่อเมื่อเกิดเหตุความยาวหนึ่งหน้า ส่งให้ทุกคนที่มีชื่อในผัง แล้วนัดทบทวนแฟ้มทั้งหมดเป็นรอบ เช่น ทุกไตรมาส

รู้ได้ยังไงว่าทำมาถูกทาง

วิธีวัดที่ง่ายที่สุดคือกลับไปที่ห้าคำถามตอนต้นครับ ครั้งแรกอาจต้องใช้เวลาหลายวันกว่าจะได้คำตอบครบ ถ้ารอบถัดไปตอบได้ภายในสิบนาทีพร้อมหลักฐานที่เปิดให้ดูได้ แปลว่าแฟ้มทำงานแล้ว

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

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

ส่งท้าย

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

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

ช่องทางการติดตาม TumWebSME

ติดตามสาระความรู้เรื่องการทำเว็บไซต์และการตลาดออนไลน์ได้ที่:

• Facebook: TumWebSME รับทำเว็บไซต์ธุรกิจ

• Instagram: @tumwebsme

• TikTok: @tumwebsme

• YouTube: TumWebSME

ติดต่องานและสอบถามบริการ

• 088-983-9386 (คุณพลอย)

• 099-856-3198 (คุณแสนนาน)