Patch SLA คือข้อสัญญาที่กำหนดว่าผู้รับจ้างดูแลระบบต้องติดตั้งแพตช์ความปลอดภัยภายในกี่วัน รายงานสถานะอย่างไร และมีผลอย่างไรถ้าทำไม่ทัน ตามรายงานเมื่อ 6 ตุลาคม 2569 FBI ปลดผู้รับจ้างที่ทำงานให้ Accenture เพราะไม่ติดตั้งแพตช์ บทความนี้เหมาะกับฝ่ายกฎหมาย ฝ่ายไอที และ DPO ที่จ้างภายนอกดูแลระบบ HR หรือ ERP
ลองนึกภาพบริษัทไทย 300 คนที่จ้างบริษัทภายนอกดูแลระบบเงินเดือนและข้อมูลพนักงาน (ตัวอย่างสมมติ) ผู้ผลิตซอฟต์แวร์ออกแพตช์มาหลายเดือนแล้ว แต่ผู้รับจ้างยังไม่ได้ลง ที่อยู่ เบอร์โทร และข้อมูลครอบครัวของพนักงานอยู่ในระบบนั้นทั้งหมด เรื่องนี้ไม่ไกลตัว เพราะข่าว FBI เป็นเรื่องแบบนี้พอดี
สรุปสั้น: ตามรายงานเมื่อ 6 ต.ค. 2569 FBI ปลดผู้รับจ้างที่ทำงานให้ Accenture หลังเหตุเจาะระบบที่อาจทำให้ข้อมูลพนักงานหลายพันคนรั่ว โดยหัวหน้าฝ่ายไซเบอร์ของ FBI ระบุว่าผู้รับจ้างไม่ติดตั้งแพตช์ กลุ่ม ShinyHunters อ้างว่าเป็นผู้ก่อเหตุ องค์กรไทยที่จ้างภายนอกดูแลระบบยังเป็นผู้ควบคุมข้อมูลตาม PDPA จึงควรเขียน Patch SLA ลงสัญญา
Patch SLA คืออะไร และข่าว FBI ปลดผู้รับจ้างเกิดอะไรขึ้น
Patch SLA คือข้อตกลงระดับการให้บริการเฉพาะเรื่องแพตช์ ใช้บอกว่าผู้รับจ้างต้องลงแพตช์ความเสี่ยงสูงภายในกี่วัน รายงานผลอย่างไร และผู้ว่าจ้างทำอะไรได้ถ้าไม่ทำตาม ข่าวนี้ไม่ได้ระบุว่าสัญญาของ FBI มีข้อกำหนดแบบนี้หรือไม่ แต่เป็นตัวอย่างว่าแพตช์ที่ตกหล่นเพียงรายการเดียวทำให้ผู้ว่าจ้างต้องปลดผู้รับจ้าง
| ประเด็น | ข้อเท็จจริงตามรายงาน |
|---|---|
| รายงานเมื่อ | 6 ต.ค. 2569 (Nextgov/FCW, SecurityWeek) |
| สิ่งที่ FBI ทำ | ปลดผู้รับจ้างที่ทำงานให้ Accenture |
| เหตุผลที่ FBI แถลง | ผู้รับจ้างไม่ติดตั้งแพตช์ความปลอดภัยของแพลตฟอร์ม |
| ระบบที่เกี่ยวข้อง | PeopleSoft ของ Oracle ตามแหล่งข่าว แพตช์ออกตั้งแต่เดือน มิ.ย. |
| ผู้ได้รับผลกระทบ | พนักงาน FBI หลายพันคน ไม่มีตัวเลขแน่ชัด |
| ผู้ก่อเหตุ | กลุ่ม ShinyHunters อ้างว่าเป็นผู้ก่อเหตุ |
หัวหน้าฝ่ายไซเบอร์ของ FBI ยืนยันการปลดหลังผู้รับจ้าง “ไม่ติดตั้งแพตช์ความปลอดภัยที่ออกมาเพื่อปกป้องแพลตฟอร์มนั้นโดยเฉพาะ” ถ้อยแถลงของ FBI ไม่ได้เอ่ยชื่อผู้รับจ้าง ส่วนข้อมูลว่าเป็น PeopleSoft และ Accenture ดูแลการจัดการแพตช์ มาจากแหล่งข่าวที่สื่อรายงาน
ข้อมูลที่รายงานว่าอาจรั่วมีที่อยู่ เบอร์โทร ข้อมูลคู่สมรส บทบาทงานด้านข่าวกรองและการสอดแนม และข้อมูลทางการแพทย์ของพนักงาน ข่าวไม่ระบุตัวเลขผู้ได้รับผลกระทบที่แน่ชัด และไม่อธิบายว่าทำไมจึงพลาดแพตช์ Accenture ไม่ตอบรายละเอียด บอกเพียงว่าภูมิใจที่ได้สนับสนุนภารกิจของ FBI
Patch SLA กระทบองค์กรไทยที่จ้างภายนอกดูแลระบบอย่างไร
Patch SLA กระทบองค์กรไทยโดยตรง เพราะหน่วยงานรัฐและองค์กรไทยจำนวนมากจ้างผู้ให้บริการภายนอกดูแลระบบ HR และ ERP ที่เก็บข้อมูลพนักงานไว้ เนื้อหาต่อจากนี้เป็นการวิเคราะห์ของผู้เขียน
จ้างภายนอกดูแลระบบแล้ว ความรับผิดตาม PDPA ย้ายไปที่ผู้รับจ้างไหม
ไม่ย้าย ผู้ควบคุมข้อมูลต้องจัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสมตามมาตรา 37(1) และต้องควบคุมผู้ประมวลผลข้อมูลที่ทำงานแทน การจ้างภายนอกจึงไม่ได้โอนความรับผิดไป ถ้าระบบ HR รั่ว องค์กรที่เก็บข้อมูลพนักงานคือฝ่ายที่ต้องตอบ สคส. และตอบพนักงาน
แพตช์ที่พลาดเป็นเรื่องเทคนิคหรือเรื่องสัญญา
เป็นทั้งสองเรื่อง แต่สัญญาเป็นตัวกำหนดว่าใครต้องทำอะไรภายในกี่วัน ถ้าสัญญาไม่เขียน ผู้ว่าจ้างอาจมีฐานเรียกร้องไม่ชัดเมื่อเกิดเหตุ ข่าว FBI ชี้ให้เห็นว่าเมื่อผู้ว่าจ้างจับได้ว่าแพตช์ตกหล่น ทางเลือกที่เหลือคือเอาผู้รับจ้างออก ซึ่งเกิดหลังข้อมูลรั่วไปแล้ว
ธุรกิจไทยแบบไหนเสี่ยงเหมือนกัน
โรงพยาบาลที่ใช้ระบบเวชระเบียนจากผู้ให้บริการภายนอก บริษัทที่จ้างดูแลระบบเงินเดือน และหน่วยงานที่ให้บริษัทภายนอกดูแล ERP เสี่ยงเหมือนกัน ตัวอย่างฝั่งโรงพยาบาลอ่านได้ใน Medyc เวชระเบียนรั่ว โปแลนด์เตรียมบังคับรับรองมาตรฐานผู้ประมวลผลข้อมูลสุขภาพ โรงพยาบาลไทยที่ใช้ HIS ภายนอกต้องระวังอะไร
ส่วนเรื่องสัญญาจ้างเขียนโค้ดภายนอกอ่านได้ใน พบรหัสผ่านและคีย์ที่ยังใช้ได้ 543,699 รายการบน GitHub สาธารณะ บริษัทไทยที่จ้าง outsource เขียนโค้ดต้องเขียนอะไรในสัญญา
ถ้าเกิดเหตุแล้ว ต้องแจ้ง สคส. เมื่อไร
ผู้ควบคุมข้อมูลต้องแจ้งเหตุละเมิดต่อ สคส. ภายใน 72 ชั่วโมงตามมาตรา 37(4) สัญญาจึงต้องบังคับให้ผู้รับจ้างแจ้งผู้ว่าจ้างทันทีที่พบเหตุ ถ้าผู้รับจ้างแจ้งช้า เวลาของผู้ว่าจ้างก็หมดไปกับการรอ แนวทางประเมินการแจ้งเหตุจากเหตุช่องโหว่จริงอ่านได้ใน ThaiCERT เตือนช่องโหว่ Zimbra CVE-2026-73570 ถูกใช้ฝัง Web Shell และดูดอีเมล องค์กรไทยต้องอัปเดตและประเมินการแจ้ง สคส. อย่างไร
ถ้าไม่เขียน Patch SLA ลงสัญญา จะเสี่ยงอะไร
ถ้าไม่เขียน Patch SLA ลงสัญญา องค์กรเสี่ยงสามเรื่อง คือแพตช์ตกหล่นโดยไม่มีใครผูกพันตามสัญญา เรียกร้องจากผู้รับจ้างได้ยากเมื่อเกิดเหตุ และไม่มีหลักฐานแสดงต่อ สคส.
- แพตช์ความเสี่ยงสูงค้างอยู่หลายเดือน เพราะสัญญาไม่กำหนดกรอบเวลาและไม่มีใครรายงาน
- เมื่อข้อมูลรั่ว ผู้ว่าจ้างอ้างข้อสัญญาเรียกให้ผู้รับจ้างรับผิดได้ยาก
- ผู้ควบคุมข้อมูลพิสูจน์ไม่ได้ว่าจัดมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสมตามมาตรา 37(1) ให้ผู้รับจ้างทำตาม
องค์กรที่จ้างภายนอกดูแลระบบควรเขียน Patch SLA อย่างไร
ควรเขียน Patch SLA ให้ครบ 5 เรื่อง คือบัญชีระบบ กรอบเวลาลงแพตช์ การรายงาน ผลเมื่อไม่ทำตาม และการแจ้งเหตุ ตัวเลขจำนวนวันต้องตกลงกันตามความสำคัญของแต่ละระบบ ไม่มีตัวเลขกลางที่ใช้ได้กับทุกที่
- 1. ทำบัญชีระบบที่จ้างภายนอกดูแล ระบุว่าระบบไหนเก็บข้อมูลส่วนบุคคลของพนักงานหรือลูกค้า และใครเป็นผู้รับจ้าง
- 2. กำหนดกรอบเวลาลงแพตช์ตามความรุนแรง แพตช์ความรุนแรงสูงต้องลงภายในกี่วัน และถ้าลงไม่ได้ต้องมีมาตรการชั่วคราวอะไร
- 3. ให้รายงานสถานะแพตช์ทุกเดือน พร้อมหลักฐาน และให้ผู้ว่าจ้างมีสิทธิตรวจสอบ
- 4. กำหนดผลเมื่อไม่ทำตาม เช่น ค่าปรับ สิทธิเปลี่ยนผู้รับจ้าง หรือสิทธิยุติสัญญา
- 5. บังคับให้แจ้งเหตุทันที ผู้รับจ้างต้องแจ้งเมื่อพบเหตุ เพื่อให้ผู้ควบคุมข้อมูลประเมินการแจ้ง สคส. ภายใน 72 ชั่วโมงได้ทัน
ถ้าต้องการคนช่วยร่าง Patch SLA และทบทวนสัญญาจ้างดูแลระบบ ดูรายละเอียดได้ที่ บริการ AI Governance และ PDPA ของ Kooru ติดตามเรื่องข้อมูลส่วนบุคคลต่อได้ที่ หมวด PDPA & Privacy
มุมมองผู้เชี่ยวชาญ
ผมมองว่าข่าวนี้สอนเรื่องลำดับเวลา ผู้ว่าจ้างปลดผู้รับจ้างได้ แต่ทำได้หลังข้อมูลรั่วไปแล้ว ข้อมูลที่หลุดไปแล้วเรียกคืนไม่ได้ สิ่งที่เขียนไว้ในสัญญาก่อนเกิดเหตุเท่านั้นที่ป้องกันได้ จุดที่องค์กรมักพลาดคือสัญญาจ้างดูแลระบบพูดถึงเวลาที่ระบบต้องใช้งานได้ แต่ไม่พูดถึงเวลาที่แพตช์ต้องลง ควรเช็กว่าสัญญามีทั้งสองอย่าง
— Phuwara Krobtaku —
LL.M. (IP & IT) | M.S. (IT) | Thai Barrister & Attorney-at-Law
คำถามที่พบบ่อยเกี่ยวกับ Patch SLA
Patch SLA คืออะไร
Patch SLA คือข้อสัญญาที่กำหนดว่าผู้รับจ้างต้องติดตั้งแพตช์ความปลอดภัยภายในกี่วัน ต้องรายงานสถานะอย่างไร และมีผลอย่างไรถ้าไม่ทำตาม ผู้ว่าจ้างใช้ข้อนี้คุมความเสี่ยงจากระบบที่จ้างภายนอกดูแล
FBI ปลดผู้รับจ้างเพราะอะไร
หัวหน้าฝ่ายไซเบอร์ของ FBI ระบุว่าผู้รับจ้างไม่ติดตั้งแพตช์ความปลอดภัยที่ออกมาเพื่อปกป้องแพลตฟอร์ม ตามรายงานเมื่อ 6 ต.ค. 2569 FBI ไม่ได้อธิบายว่าทำไมแพตช์จึงตกหล่น
ใครอยู่เบื้องหลังเหตุเจาะระบบ FBI
กลุ่ม ShinyHunters อ้างว่าเป็นผู้ก่อเหตุ เป็นการอ้างของกลุ่มเอง ข่าวต้นทางไม่ได้บอกว่า FBI ยืนยันชื่อกลุ่ม
Patch SLA ควรกำหนดแพตช์ภายในกี่วัน
ไม่มีตัวเลขกลางที่ใช้ได้กับทุกระบบ ข่าว FBI ก็ไม่ได้ระบุกรอบเวลา ควรตกลงตามความรุนแรงของช่องโหว่และความสำคัญของระบบที่เก็บข้อมูลส่วนบุคคล
จ้างภายนอกดูแลระบบแล้วต้องรับผิดตาม PDPA ไหม
ต้องรับผิด ผู้ควบคุมข้อมูลยังมีหน้าที่จัดมาตรการรักษาความมั่นคงปลอดภัยตามมาตรา 37(1) และควบคุมผู้ประมวลผลที่ทำงานแทน การจ้างภายนอกไม่ได้โอนความรับผิดไป
แหล่งอ้างอิง
- Nextgov/FCW — (อ่านต้นฉบับ) — อ่านข่าวที่ Nextgov/FCW
- SecurityWeek — (อ่านต้นฉบับ) — อ่านข่าวที่ SecurityWeek
บทความนี้เป็นการสรุปข่าวและให้ข้อมูลทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย หากต้องการคำปรึกษาเฉพาะกรณีของธุรกิจคุณ ควรปรึกษาผู้เชี่ยวชาญ
