บทนำ
วันที่ 11 กันยายน 2569 เป็นวันที่ธุรกิจที่เกี่ยวข้องกับตลาดยุโรปต้องจับตา เพราะข้อกำหนดด้านการรายงานเหตุด้านความมั่นคงปลอดภัยไซเบอร์บางส่วนของ Cyber Resilience Act (CRA) จะเริ่มมีผล โดยเพิ่มชั้นของการรายงานเข้ามาจากกรอบกฎหมายยุโรปที่มีอยู่แล้ว
IAPP วิเคราะห์ประเด็นนี้ผ่านแนวคิด “สี่นาฬิกา เหตุเดียว” โดยชี้ว่าในบางกรณี โดยเฉพาะบริบท HealthTech และ MedTech เหตุการณ์เดียวอาจไปเกี่ยวข้องกับ GDPR, NIS2, กฎเฝ้าระวังอุปกรณ์การแพทย์ และ CRA พร้อมกัน สิ่งที่น่ากลัวกว่าการมีหลาย deadline คือ รายงานครั้งแรกอาจกลายเป็นบันทึกข้อเท็จจริงที่ถูกนำไปเทียบกับการแจ้งเหตุครั้งต่อ ๆ ไป
พูดง่ายๆ คือ เรื่องไม่ได้จบที่ “แจ้งทันหรือไม่ทัน” แต่ยังมีคำถามว่า บริษัทกำลังเล่าเรื่องเดียวกันให้ทุกกฎหมายฟังด้วยข้อมูลชุดเดียวกันหรือเปล่า
ข้อเท็จจริง
CRA เป็นกฎหมายของสหภาพยุโรปที่วางข้อกำหนดด้านความปลอดภัยไซเบอร์สำหรับ “ผลิตภัณฑ์ที่มีองค์ประกอบดิจิทัล” และกำหนดหน้าที่สำคัญกับผู้ผลิต รวมถึงการจัดการช่องโหว่และเหตุการณ์ด้านความมั่นคงปลอดภัยของผลิตภัณฑ์
ส่วนที่เริ่มใช้วันที่ 11 กันยายน 2569 คือภาระการรายงานเกี่ยวกับช่องโหว่ที่ถูกโจมตีจริงและเหตุการณ์ร้ายแรงที่กระทบต่อความปลอดภัยของผลิตภัณฑ์ ไม่ใช่การที่ข้อกำหนดทั้งหมดของ CRA มีผลพร้อมกันในวันดังกล่าว โดยตัว CRA โดยทั่วไปจะเริ่มใช้วันที่ 11 ธันวาคม 2570
ตามข้อมูลล่าสุดจาก ENISA ระบบ CRA Single Reporting Platform (SRP) ถูกออกแบบให้เป็นช่องทางกลางสำหรับการรายงานภายใต้ CRA และช่วยให้ผู้ผลิตส่งข้อมูลผ่านจุดเดียว แทนการต้องแจ้งไปยังหน่วยงานระดับประเทศหลายแห่งแยกกัน
สำหรับการรายงานภายใต้ CRA มีกรอบเวลาหลักที่ต้องจำให้แม่น ได้แก่
ภายใน 24 ชั่วโมง — Early Warning หลังผู้ผลิตทราบถึงช่องโหว่ที่ถูกโจมตีจริงหรือเหตุการณ์ที่เข้าเกณฑ์
ภายใน 72 ชั่วโมง — รายงานเหตุการณ์พร้อมข้อมูลและการประเมินเบื้องต้น
รายงานฉบับสุดท้าย — สำหรับช่องโหว่ต้องส่งไม่เกิน 14 วันหลังมีมาตรการแก้ไข เช่น patch พร้อมใช้งาน และสำหรับเหตุการณ์ร้ายแรงต้องส่งภายใน 1 เดือนหลังการแจ้งครั้งแรก
“กรอบเวลา” ไม่ได้แปลตรงๆ ว่าบริษัททุกแห่งจะต้องโทรแจ้งสี่หน่วยงานพร้อมกัน แต่หมายถึงเหตุการณ์เดียวอาจถูกพิจารณาภายใต้หลายกรอบกฎหมาย ซึ่งแต่ละกรอบมีผู้มีหน้าที่ เกณฑ์ และเวลาเริ่มนับต่างกัน
ตัวอย่างที่เห็นภาพชัด คือ GDPR กำหนดให้ผู้ควบคุมข้อมูลแจ้งเหตุละเมิดข้อมูลส่วนบุคคลต่อหน่วยงานกำกับโดยไม่ชักช้า และโดยทั่วไปไม่เกิน 72 ชั่วโมงนับจากเวลาที่ทราบเหตุ เว้นแต่เหตุไม่มีแนวโน้มก่อความเสี่ยงต่อสิทธิและเสรีภาพของบุคคล
ขณะที่ NIS2 ก็ใช้แนวคิดการแจ้งเตือนหลายช่วง โดยกำหนด early warning ภายใน 24 ชั่วโมง และ incident notification ภายใน 72 ชั่วโมงสำหรับเหตุที่เข้าเกณฑ์
ดังนั้น ประโยคสำคัญที่สุดของเรื่องนี้อาจไม่ใช่ “EU มี deadline ใหม่” แต่คือ เหตุการณ์เดียวอาจเริ่มนับเวลาจากคนละจุด และถูกอธิบายด้วยคนละกฎหมาย
ผลกระทบต่อธุรกิจในประเทศไทย
สำหรับบริษัทไทยที่ขายซอฟต์แวร์ อุปกรณ์เชื่อมต่อ ระบบ IoT หรือผลิตภัณฑ์ดิจิทัลเข้าสู่ตลาดยุโรป เหตุไซเบอร์หนึ่งครั้งอาจไม่ได้เป็นเพียงปัญหา IT อีกต่อไป เช่น เซิร์ฟเวอร์ของบริษัทถูกโจมตีและทำให้ระบบที่เชื่อมต่อกับอุปกรณ์ลูกค้าในยุโรปหยุดทำงาน เหตุการณ์เดียวกันอาจนำไปสู่การประเมินทั้งด้านความปลอดภัยของผลิตภัณฑ์ ความมั่นคงปลอดภัยของบริการ และข้อมูลส่วนบุคคล ขึ้นอยู่กับลักษณะของเหตุและบทบาทของแต่ละบริษัท
จุดที่ธุรกิจไทยมักพลาดคือการแยกทีมทำงานเป็นส่วน ๆ เช่น ทีม IT เขียน incident report, ทีมกฎหมายทำ PDPA assessment, ทีม Compliance ทำรายงานตามคู่ค้า และทีม Customer Success แจ้งลูกค้าอีกชุดหนึ่ง ปัญหาคือแต่ละทีมอาจใช้ “ข้อเท็จจริงคนละเวอร์ชัน” ทั้งเรื่องเวลาที่ตรวจพบ ขอบเขตของเหตุ จำนวนระบบที่ได้รับผลกระทบ หรือว่าข้อมูลใดได้รับผลกระทบ
เมื่อเกิดเช่นนี้ ความเสี่ยงไม่ได้จบแค่เรื่องส่งไม่ทัน แต่บริษัทอาจต้องเสียเวลาอธิบายว่า ทำไมรายงานฉบับแรกบอกอย่างหนึ่ง แต่รายงานฉบับถัดไปบอกอีกอย่างหนึ่ง
สำหรับไทย บทเรียนนี้ยิ่งสำคัญ เพราะการรับมือเหตุไม่ได้มีแค่เรื่องความปลอดภัยทางไซเบอร์ แต่ยังต้องพิจารณากฎหมายคุ้มครองข้อมูลส่วนบุคคลและข้อกำหนดเฉพาะของธุรกิจด้วย สคส. เองก็มีระบบที่สนับสนุนการจัดการและแจ้งเหตุละเมิดข้อมูลส่วนบุคคลภายในกรอบ 72 ชั่วโมง
ดังนั้น สิ่งที่ธุรกิจควรสร้างไม่ใช่ “แบบฟอร์มแจ้งเหตุ 5 แบบ” แต่เป็น ฐานข้อเท็จจริงกลางของเหตุการณ์เดียว แล้วค่อยนำข้อมูลชุดนั้นไป map ว่ากฎหมายใดบ้างเกี่ยวข้อง ต้องแจ้งใคร แจ้งเมื่อไร และข้อมูลระดับไหนที่สามารถยืนยันได้ในแต่ละช่วง
แนวคิดนี้สำคัญมากสำหรับบริษัทที่มีบริษัทแม่ในต่างประเทศ เพราะการแจ้งครั้งแรกจากทีมไทยอาจถูกนำไปใช้ต่อในระดับกลุ่มบริษัทหรือใช้ตอบคำถามของลูกค้าและ regulator ต่างประเทศได้
พูดแบบง่ายที่สุดคือ
อย่าออกแบบ Incident Response จากคำถามว่า “กฎหมายนี้ต้องแจ้งอะไร?” แต่ออกแบบจากคำถามว่า “เรารู้ข้อเท็จจริงอะไรแล้ว และข้อเท็จจริงชุดนี้ต้องไปตอบกฎหมายไหนบ้าง?”
นี่คือการเปลี่ยน Incident Response จาก “งานแจ้งเหตุ” เป็น ระบบบริหารข้อเท็จจริงภายใต้เวลาที่มีจำกัด
สิ่งที่ควรทำต่อ — ก่อนเกิดเหตุจริง ควรมี “Single Incident Fact Base”
1. ทำ Incident Timeline กลาง
บันทึกเวลาที่พบเหตุ เวลาที่ยืนยันเหตุ เวลาที่รู้ประเภทข้อมูลหรือระบบที่ได้รับผลกระทบ และเวลาที่เริ่ม escalation เพื่อให้ทุกทีมใช้ timeline เดียวกัน
2. ทำ Regulatory Trigger Matrix
กำหนดล่วงหน้าว่าเหตุแบบไหนอาจเกี่ยวกับ PDPA, NIS2, CRA, ข้อกำหนดของคู่ค้า หรือกฎหมายเฉพาะอุตสาหกรรม และแต่ละกรอบมี deadline เท่าไร
3. แยก “ข้อเท็จจริงที่ยืนยันแล้ว” ออกจาก “ข้อสันนิษฐาน”
ในช่วง 24 ชั่วโมงแรก บริษัทอาจยังไม่รู้ทุกอย่าง จึงควรระบุให้ชัดว่าอะไร confirmed, อะไร under investigation และอะไรยังไม่ทราบ แทนการเติมข้อมูลเพื่อให้รายงานดูสมบูรณ์
4. ทำแบบฟอร์มแจ้งเหตุที่แตกออกจาก Fact Base เดียว
อย่าให้ทีมแต่ละกฎหมายเขียนเรื่องใหม่ตั้งแต่ต้น ให้ใช้ข้อมูลกลางชุดเดียว แล้ว generate ส่วนที่แตกต่างตามข้อกำหนดแต่ละระบบ
5. ซ้อมเหตุแบบ “หลายกฎหมายพร้อมกัน”
Tabletop Exercise ครั้งต่อไปไม่ควรถามแค่ว่า “ถ้าโดน ransomware จะทำอย่างไร” แต่ควรถามว่า “ถ้าเหตุเดียวกันกระทบข้อมูลส่วนบุคคล + ผลิตภัณฑ์ + ลูกค้า EU ใครเป็นคนเริ่มนับเวลา และใครเป็นเจ้าของข้อเท็จจริงชุดกลาง?”
ทำไมเรื่องนี้จึงสำคัญกับบริษัทไทย แม้ไม่ได้อยู่ยุโรป
สิ่งที่ CRA กำลังบอกธุรกิจทั่วโลกไม่ใช่แค่เรื่อง “กฎหมาย EU เพิ่มอีกฉบับ” แต่คือยุคของการรับมือเหตุไซเบอร์กำลังเปลี่ยนจากการมี Incident Response Plan ไปสู่การมี Multi-Clock Incident Response
เมื่อบริษัทมีลูกค้าต่างประเทศ ใช้ Cloud ต่างประเทศ มีบริษัทแม่อยู่ต่างประเทศ หรือขายผลิตภัณฑ์ดิจิทัลข้ามพรมแดน การตอบสนองต่อเหตุหนึ่งครั้งอาจต้องวิ่งหลายเส้นทางพร้อมกัน
ประเทศไทยจึงควรมองปัญหานี้ในฐานะ “แบบฝึกหัด” ก่อนกฎต่างประเทศจะเข้ามาชนกับกระบวนการภายในจริง
และประเด็นที่น่าสนใจที่สุดคือ วิธีคิดนี้นำกลับมาใช้กับองค์กรไทยได้ทันที เพราะแม้ชื่อกฎหมายและผู้กำกับจะต่างกัน แต่โจทย์พื้นฐานเหมือนกัน:
เกิดอะไรขึ้น — ใครได้รับผลกระทบ — เรารู้เมื่อไร — ต้องแจ้งใคร — และข้อมูลที่แจ้งครั้งแรกจะถูกนำไปใช้อ้างอิงต่ออย่างไร
แหล่งอ้างอิง
IAPP — “Four clocks, one incident: What the CRA adds to EU incident notifications”
บทวิเคราะห์โดย Georgia Chatzitheodorou, CIPP/E, CIPP/US, เผยแพร่ 28 สิงหาคม 2569
อ่านบทความต้นฉบับ IAPP
ENISA — CRA Single Reporting Platform FAQ
รายละเอียดระบบรายงานกลางและกรอบเวลา 24 ชั่วโมง / 72 ชั่วโมง / Final Report
EUR-Lex — Cyber Resilience Act (Regulation (EU) 2024/2847)
ข้อมูลวันเริ่มใช้และข้อกำหนดการรายงานภายใต้ CRA
EUR-Lex — GDPR Article 33
กรอบการแจ้งเหตุละเมิดข้อมูลส่วนบุคคล 72 ชั่วโมง
EUR-Lex — NIS2 Article 23
กรอบ Early Warning 24 ชั่วโมง และ Incident Notification 72 ชั่วโมง
สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) — GPPC Plus
ข้อมูลระบบสนับสนุนการจัดการเหตุละเมิดข้อมูลส่วนบุคคลภายในกรอบ 72 ชั่วโมง
