事件剛發生時最容易犯的錯，是一邊刪檔、一邊改設定，卻沒有保存時間、來源與受影響範圍。有效回報要讓處理者能重建事件、評估嚴重度並採取隔離，而不是只有一句「網站被駭」。
先建立事件編號與單一時間線
收到通報後立即建立事件 ID，所有截圖、日誌、決策與溝通都引用同一編號。時間統一使用含時區的 ISO 8601：
2026-08-01T02:41:18+08:00 ALERT WAF detected anomalous upload
2026-08-01T02:44:03+08:00 ACTION Isolated web node web-03
2026-08-01T02:51:27+08:00 EVIDENCE Collected disk snapshot snap-8f31不要事後憑記憶補寫；每一項操作都要記錄執行者、原因與結果。
回報內容要能被直接採取行動
最低資訊包含：發現時間、資產、症狀、重現條件、受影響帳號或資料、目前是否仍持續、已採取措施與聯絡人。可用結構化格式降低遺漏：
{
"incident_id": "INC-2026-0801-01",
"asset": "admin.kaelith.tw",
"detected_at": "2026-08-01T02:41:18+08:00",
"severity": "high",
"indicator": "unexpected administrator session",
"containment": ["revoked session", "disabled affected account"],
"evidence": ["auth-log-0801.jsonl", "screenshot-01.png"]
}Token、密碼與完整個資不要直接貼入一般工單；使用受控附件或證據庫。
依影響與可利用性分級
- 重大：核心系統中斷、管理權限被接管、大量敏感資料外洩或攻擊仍持續。
- 高：已確認未授權存取、可被遠端利用的高權限漏洞、付款或身分系統受影響。
- 中：影響有限、需要特定條件、已有補償控制。
- 低：資訊性問題、無直接安全影響或僅限測試環境。
分級要同時看機密性、完整性、可用性、影響人數、外部曝露與修復難度。
隔離前先考慮證據與業務影響
能立即停用的惡意帳號應先撤銷；但關機、重灌或刪檔可能破壞記憶體與時間戳。高嚴重事件由事件指揮者決定隔離順序，必要時先擷取快照、程序、連線與日誌，再切斷流量。
所有變更都應可回復，並保留原始證據的雜湊與唯讀副本。
建立清楚的通報與決策角色
至少區分事件指揮、技術調查、系統維運、法務／隱私、對外溝通與業務負責人。對外說明只由指定窗口發布，避免不同人提供矛盾資訊。
是否通知客戶、主管機關或合作夥伴，應依資料類型、契約與適用法規，由法務或合規角色判斷；技術團隊負責提供可靠時間線與影響證據。
結案必須留下修復驗證與後續責任
- 確認入口已修補，不能只清除表面症狀。
- 撤銷受影響憑證、Token、Cookie 與金鑰。
- 驗證監控能偵測相同手法。
- 記錄根因、促成條件與未生效的控制。
- 為每個改善項目指定負責人與期限。
結案報告應區分已確認事實、合理推論與未知事項，避免把尚未證實的猜測寫成定論。
結案證據
事件時間線、根因、影響範圍、修復提交、憑證輪替與監控驗證都應有可追溯證據，不能只以「目前看起來正常」結案。