หลังจดหมายรอบแรก บริษัทเติมข้อมูลลงหน้าเดิมเป็นระยะ แต่ละรอบเพิ่มข้อมูลคนละชนิด ลำดับด้านล่างใช้วันที่ตามที่หน้าแถลงบันทึกไว้
| วันที่ (2567) |
สิ่งที่เพิ่ม |
ลงชื่อหรือออกในนามใคร |
| 19 ก.ค. |
จดหมายรอบแรก |
CEO |
| 22 ก.ค. |
เริ่มใช้วิธีกู้เครื่องแบบอัตโนมัติ (ระบุในคำถามที่พบบ่อยภายหลัง) |
บริษัท |
| 24 ก.ค. |
รายงานเบื้องต้นหลังเหตุการณ์ (Preliminary Post Incident Review) บอกว่าอัปเดตเป็นแบบไหน ทดสอบอย่างไร และจะทำอะไรเพิ่ม |
บริษัท |
| 25 ก.ค. |
ตัวเลขเครื่องที่กลับมาออนไลน์ มากกว่าร้อยละ 97 เมื่อเทียบกับสัปดาห์ก่อนเกิดเหตุ |
บริษัท |
| 31 ก.ค. |
ตัวเลขชุดสุดท้าย ราวร้อยละ 99 ณ วันที่ 29 ก.ค. พร้อมหมายเหตุว่าปกติตัวเลขนี้แกว่งราวร้อยละ 1 ต่อสัปดาห์ |
บริษัท |
| 6 ส.ค. |
รายงานวิเคราะห์สาเหตุฉบับเต็ม (Root Cause Analysis) บทสรุปผู้บริหาร และจดหมายฉบับที่สองของ CEO |
บริษัทและ CEO |
รายงานฉบับเต็มอธิบายสาเหตุว่าโปรแกรมในเครื่องรอรับข้อมูล 20 ช่อง แต่อัปเดตส่งมา 21 ช่อง ความไม่ตรงกันทำให้โปรแกรมอ่านหน่วยความจำเกินขอบเขตจนเครื่องค้าง บริษัทระบุว่าผลวิเคราะห์ร่วมกับผู้ตรวจภายนอกยืนยันว่าจุดบกพร่องนี้ไม่เปิดช่องให้ผู้โจมตีใช้ประโยชน์ รายงานยังบอกว่าเครื่องมือตรวจอัปเดตก่อนปล่อยมีข้อผิดพลาดทางตรรกะ ทำให้อัปเดตที่มีปัญหาผ่านการตรวจ และรายการสิ่งที่แก้แล้วกับสิ่งที่จะแก้ พร้อมวันกำหนด เช่น การปล่อยอัปเดตเป็นขั้นให้เครื่องกลุ่มเล็กก่อน การให้ลูกค้าเลือกได้เองว่าจะรับอัปเดตแบบไหน และการจ้างผู้ตรวจความปลอดภัยซอฟต์แวร์ภายนอกสองรายมาทบทวน
จดหมายฉบับที่สองของ CEO ต่างจากฉบับแรก ฉบับนี้ขอบคุณลูกค้าและพันธมิตรที่ช่วยกู้ระบบ ยกตัวเลขร้อยละ 99 ชี้ไปที่รายงานฉบับเต็ม และขอโทษอีกครั้ง พร้อมเขียนว่าไม่มีอะไรสำคัญกว่าการได้ความไว้วางใจกลับคืนมา
ทำไมต้องออกรายงานเบื้องต้นก่อนรู้สาเหตุทั้งหมด
เพราะช่วงห้าวันหลังเหตุการณ์ ลูกค้าต้องตัดสินใจเองว่าจะรับอัปเดตต่อไหม และต้องอธิบายให้ลูกค้าของตัวเองฟัง รายงานเบื้องต้นระบุไว้ในย่อหน้าแรกว่าเป็นฉบับเบื้องต้น และบอกล่วงหน้าว่าจะเผยแพร่รายงานวิเคราะห์สาเหตุฉบับเต็มต่อสาธารณะ ผู้อ่านจึงรู้ว่ายังมีข้อมูลตามมา และรู้ว่าตอนนี้บริษัทยืนยันได้แค่ไหน