中小企遇到網絡事故，首份事件時間線應記錄甚麼？

及早建立單一事故紀錄

疑似網絡事故的第一個小時通常很混亂：員工發現異常登入，另一位看到系統連接失敗，顧客又回報可疑電郵。這些線索可能相關，也可能碰巧同時出現。團隊未確定原因前，先開一份有暫定編號及負責人的事故紀錄，寫下每項資料由誰提出、何時觀察到、涉及哪個系統，以及原始證據可在哪裏找到。把它標示為「觀察」，不要立即寫成已確認資料外洩。NIST 現行事故應對文件把準備、偵測、處理及復原視作相連的風險管理工作；可追溯時間線正好協助事實在各階段之間傳遞。

首份紀錄要簡單到忙碌員工願意使用。每一列可記事件發生時間、團隊得知時間、來源、簡短描述、確定程度或狀態，以及下一步負責人。顧客在上午十時二十分來訊，可能說上午九時五十分已看到可疑電郵；那是兩個不同時間。應用程式日誌又可能記錄第三個時間。不要默默把它們整理成看似完美的故事，應先分開標明「回報時間」與「日誌所示時間」，待核實後再更新。這樣可以避免一開始的猜測，變成隔離系統、對客說明或事後檢討的無條件前提。

統一時間但保留原始時標

先原樣保存來源顯示的時間，包括時區或偏移量；確認來源時區後，才另加一欄換算成團隊約定的工作時間，例如香港時間。若來源時區未知，就註明未知，不要假設手提電腦、雲端服務與員工手機都用同一設定。日後發現某系統時鐘有偏差，亦要補記。NIST 的日誌管理指引強調時間資料和時鐘同步對分析的重要性。若時間線假裝所有時標天然可直接比較，便可能把處理行動排在觸發它的事件之前，誤導判斷。

例如託管服務以 UTC 記警報，客服則用香港時間寫筆記。整理時間線的人應保留兩段原始時標，再記下換算後可比較的時間及換算方法。若之後發現警報來源時鐘慢了五分鐘，應新增更正註記並交代依據，不要改寫原始日誌內容。這個例子只是流程示範，不代表真實事故，也沒有聲稱縮短了多少處理時間。重點是其他同事能重現為何判定兩件事同時、先後或互不相關，並在取得更可靠證據時修正判斷。

分清每種來源能證明甚麼

登入日誌可能證明某憑證被接受，卻不能單憑這筆資料識別鍵盤前的人。顧客截圖顯示某部裝置所見畫面，但不能證明所有收件人都看到相同內容。監察警報說明規則曾觸發，未必等於資料已匯出。每項證據都應寫明它能支持的狹義事實，以及尚未排除的其他解釋。連到原始紀錄或受控副本，記下來源系統與取得時間；不要為求方便，把整批個人資料貼入很多人可看的事故群組。時間線應幫助找回證據和決策，而不是變成失控的敏感資料副本。

先處理短暫存在的資料。有些日誌會輪替，儀表板畫面會更新，員工裝置也可能繼續使用。事故負責人應找出哪些來源快要消失，在例行清理前安排獲授權的匯出或保存。記錄由誰取得副本、如何取得、存在哪裏，以及曾用甚麼完整性檢查。有人存了截圖，並不代表已建立正式證據保管鏈。若可能進入正式調查或法律程序，應找合適專業人士並遵循公司證據處理政策。NIST 的一般事故指引本身不會令中小企筆記自動變成可在法庭採納的證據。

把處理行動與觀察並列

時間線除了系統回報，還要記錄應對人員做了甚麼。停用帳戶、撤銷權杖、隔離裝置、更改規則或恢復服務，都應註明決策者、理由及實際執行時間。處理行動可能改變原本想保護的證據：重新啟動伺服器可能清除暫存資料，繼續讓它上線又可能擴大損害。正確做法取決於事故及可用專業支援。簡短記下曾考慮的選項，比事後只寫「已依程序處理」更能說明當時看到了甚麼、為何選擇該措施。

建議、獲批、開始及完成的行動應有不同狀態。「應該撤銷金鑰」這句訊息，不能證明金鑰已撤銷。採取行動後，應到相關系統核實結果，並把核實觀察新增為另一條紀錄；若核實失敗，保留未完成狀態和下一步負責人。多人跨班處理時，接手者才能知道帳戶是真的已停用，還是只提出了要求。這亦避免事後報告把意圖寫成已完成的控制措施。包含內部操作細節的時間線須限制存取；對客戶的更新則應另用經批准的摘要。

用可見更正逐步修訂

首份時間線只是暫定版本。指定負責人在取得新日誌、供應商回報或員工補充記憶後，逐條覆查未確定事項。保留原說法，再附加更正或新評估，寫明新的來源和時間；修正事件時間不應令早前回報消失。維持一張簡短待查清單，例如哪些帳戶受影響、可疑操作有否成功、存取何時終止，以及哪些證據仍缺。結案時要寫下為何認為問題已解答，不能只打勾。最後檢討才會是可追溯的重建，而非靠記憶整理得漂亮的故事。

結束檢討時，應比較最初推測與最終核實結果：哪個來源最關鍵、哪項資料缺失、處理過程有否令事後重建更困難。只有證據顯示真正缺口時，才調整日誌、保存期或應對流程。NIST 第三版建議支持持續改善事故處理能力，但不會替每家公司規定同一張萬用表格。對小團隊來說，眼前較實際的成果，是一份清楚區分事實與推論、保留原始線索、讓下一位處理者能作較安全決策的紀錄。若仍有無法確認之處，最終說明亦應明白列出。

用小型情境演練

事故發生前，可用一個簡短桌面情境測試模板：員工報告陌生管理員登入，日誌似乎支持此說法，但雲端供應商儀表板資料延遲。請一人記下觀察，一人找出快將輪替的證據，由決策者記錄是否應暫停存取。然後加入更正：日誌用 UTC，員工回報用香港時間。團隊應更新工作時間線，但不得刪除任何原始時標。這項練習可揭示員工是否知道日誌位置、誰有權匯出，以及如何交班；它不能證明公司可應付所有攻擊，只能測試首份紀錄能否支持有理據的下一步。

交班時，請接手者說出哪些已證實、哪些只是推論、還有哪些需要核對。若他找不到原警報、無法確定金鑰是否真的撤銷，或不知道來源時區，時間線便需要改善。把紀錄放在受限制位置，指定負責人，僅讓真正參與應對的人存取；之後按公司的義務和政策決定保存多久，不要讓方便使用的事故資料夾變成永久公開倉庫。若涉及個人資料或受規管系統，應在作通知或法律結論前尋求相關專業判斷。良好的早期時間線可以支援那些決定，但不能取代判斷本身。

事故複雜時，可另設決策紀錄，但仍要連到同一時間線編號。決策紀錄保存由誰批准會影響服務的措施、曾考慮甚麼選項，以及何時重新評估是否撤回；時間線則記實際執行時間及核實結果。這可避免重要承諾被長篇敘述淹沒。供應商或專家稍後加入，也能先讀現時已知事實、待查問題及已授權行動，而不用取得所有無關顧客資料。每次交班，應指出哪些證據可能在下次覆核前消失、由誰負責保存。只說「仍在調查」的交班，會把最趕急的工作交給運氣。