安全事件最困難的部分通常發生在事件結束之後：企業必須說明發生了什麼事、何時發現、涉及哪些資料、有哪些人受到影響，以及為何做出某些決定。
對許多中小企業而言，這些記錄並不存在完整的形式。詳細資料可能散落在聊天訊息、收件匣、服務台工單、螢幕擷取畫面，以及團隊成員的記憶中。企業在事件期間靠這些拼湊而成的記錄勉強撐過去，但當監管機關、保險公司、客戶或董事會成員要求提供清楚的時間軸時，這些記錄就成了問題。
各種規模的企業都需要一份詳盡的安全事件日誌。它應該是記錄真相的單一來源，用來記錄發生了什麼事、事件如何處理，以及有哪些證據支持過程中做出的決定。
即使不需要通報事件，這些記錄仍有其價值。我們將說明安全事件日誌為何對您的企業有幫助，以及如何建立您自己的日誌。
安全事件日誌為何重要
安全事件日誌能在企業最容易遺漏詳細資料的時刻建立問責機制。事件期間，各項行動迅速展開：重設密碼、停用帳號、聯繫 IT 供應商、檢查客戶資料，以及向領導層簡報。這些步驟當下或許正是企業所需，但若沒有人記錄每項行動發生的時間、由誰核准，以及有哪些證據支持該決定，日後就難以清楚說明。
對總部設於歐洲的企業而言，這不僅是優良做法。根據英國和歐盟的《一般資料保護規則》 (GDPR)，個人資料外洩必須經過評估，部分外洩事件還必須通報給相應的監管機關。
在英國，ICO 的通報資料外洩(新視窗)指引說明，組織必須評估對民眾權利與自由的可能風險，並在風險可能發生時通知 ICO。第 33 條也要求控管者記錄個人資料外洩，包括外洩的事實、影響，以及採取的補救措施。歐盟 GDPR 也適用相同的要求。
舉例來說，ICO 並不期望每家中小企業都擁有企業級系統，但確實期望有適當的記錄。其外洩回應與監控架構指出，組織應制定程序，確保個人資料事件與外洩能被偵測、管理並適當記錄。這表示事件日誌不應只在嚴重外洩發生後才建立，而應是正常回應流程的一部分。
良好的記錄也有助於保險理賠。網路保險公司可能會要求提供證據，說明事件的發現時間、採取了哪些遏制步驟、哪些帳號受到影響，以及企業是否遵循其事件回應流程。妥善保存的日誌可以顯示企業即時且一致地採取行動。
這也有助於公司從中學習。記憶和口頭記錄並不可靠，但一份記錄若能顯示事件始於重複使用的密碼、缺少多重要素驗證 (MFA)、供應商存取權限，或延遲的離職流程，就能讓企業有具體的問題可修正，並為日後強化安全提供更明確的方向。
事件日誌與事件回應方案的差異
安全事件日誌和事件回應方案彼此相關，但兩者並非同一份文件。
事件回應方案說明企業在出錯時應採取的行動。它會指派角色、呈報途徑、遏制步驟、溝通職責和復原程序。事件日誌則記錄實際發生的情況。它是特定事件的時間軸、證據軌跡、決定記錄和後續追蹤檔案。
這項區別很重要，因為即使是完善的方案，少了記錄也可能失效。企業或許採取了正確的步驟，但日後仍難以證明。日誌應能協助回答實際問題：我們何時得知、誰採取行動、我們遏制了什麼、哪些資料面臨風險、我們做了什麼決定，以及之後有什麼改變？
| 事件回應方案：您的企業應採取的行動 | 安全事件日誌：實際發生的情況 |
| 由誰主導回應 由誰聯繫 IT、法務、保險公司或監管機關 如何遏制、復原和溝通 | 事件何時被發現 哪些系統和資料受到影響 採取了哪些行動、由誰執行，以及何時執行 |
安全事件日誌應包含的內容
實用的事件日誌必須具備足夠的一致性，讓企業日後能重建事件經過，並說明回應期間所做的決定。
發現的日期與時間
記錄企業首次察覺事件的時間、由誰發現，以及如何發現。若時間為約略值，請標記為約略。發現時間很重要，因為 GDPR 的通報時限和保險要求往往取決於企業何時察覺該問題。
事件性質
以淺顯的語言描述發生了什麼事。避免使用「安全問題」或「可能外洩」等缺乏背景的模糊標籤。日誌應說明哪些系統受到影響，以及事件是否涉及憑證、電子郵件、檔案、客戶資料、付款系統、端點或第三方存取。
涉及的資料
若個人資料可能受到影響，請記錄涉及的資料類型：姓名、電子郵件地址、電話號碼、地址、帳號詳細資料、財務資訊、員工記錄、客戶通訊、登入憑證，或任何其他相關類別。預估可能受影響的人數，並清楚說明該數字是已確認或仍在調查中。
可能原因
記錄已知或可疑的原因，即使調查仍在進行中。隨著新詳細資料出現，日誌可從「原因不明」更新為「網路釣魚電子郵件導致憑證入侵」或「前承包商帳號仍處於啟用狀態」。日誌應顯示企業的理解如何隨時間改變。
立即遏制行動
記錄為限制損害所採取的行動。這可能包括重設密碼、撤銷工作階段、強制執行 MFA、暫停帳號、移除電子郵件信箱規則、隔離裝置、移除供應商存取權限、變更防火牆，或暫時關閉服務。若可能，請包含每項行動的負責人和時間戳記。
通知決定
記錄企業是否通知相關監管機關（英國為 ICO，歐盟其他地區則為各國資料保護主管機關）、受影響的個人、客戶、供應商、保險公司、法律顧問或執法機關。若決定不通報，請記錄理由。這項說明往往與通知本身同樣重要。
補救步驟與時間軸
遏制是處理當下的事件。補救則是降低同一問題再次發生的機會。記錄後續行動，例如強制執行 MFA、移除共享憑證、更新存取政策、改善離職流程、修正錯誤設定，或變更備份的保護方式。
經驗教訓
最後寫下企業學到什麼以及將有什麼改變。這不應寫成究責。應指出弱點、所需的改善，以及由誰負責後續追蹤。
適合中小企業的簡易事件日誌範本
記錄事件不需要專業軟體。只要存取受到控制且記錄保持一致，試算表、安全的內部表單、工單系統或共享登記表都能派上用場。
有效的事件日誌應包含以下欄位：
- 事件 ID： 唯一的參考編號。
- 發現的日期與時間： 企業察覺事件的時間。
- 通報者：員工、供應商、客戶、廠商、監控警示或外部單位。
- 事件類型：網路釣魚、惡意軟體、憑證入侵、資料遺失、未經授權的存取、勒索軟體、供應商事件、裝置遺失、誤寄的電子郵件或其它。
- 摘要：以淺顯易懂的用語說明發生了什麼事。
- 受影響的系統：涉及的應用程式、帳號、裝置、資料庫、收件匣或第三方服務。
- 涉及的資料：個人資料是否受到影響、屬於何種類型，以及可能有多少人受到波及。
- 可能原因：已知、疑似或調查中。
- 圍堵措施：立即採取了什麼行動。
- 通知決策：通知監管機關、當事人、客戶、保險公司，或決定不通知並說明理由。
- 證據連結：螢幕擷取畫面、工單、日誌、電子郵件、存取記錄、匯出檔案或供應商報告。
- 補救措施：圍堵後採取的步驟。
- 負責人：負責後續追蹤的人員。
- 狀態：待處理、監控中、已圍堵、已解決、已關閉。
- 經驗教訓：應該改變什麼。
如何記錄通知決策
通知決策值得在資安事件日誌中擁有專屬的記錄空間，因為這類決策常在事件過後被重新檢視。
根據英國與歐盟的 GDPR，當發生個人資料外洩時，組織必須評估對當事人權利與自由的可能風險。若風險很可能發生，必須盡快通知監管機關，並在可行的情況下於 72 小時內通知：英國為 ICO(新視窗)，各歐盟會員國則為該國的資料保護主管機關。若風險很高，也必須在無不當延遲的情況下通知受影響的當事人。兩地的門檻與時限相同，只有主管機關不同。
良好的事件日誌應顯示企業確實做了這項評估，並記錄是否涉及個人資料、可能造成何種損害、當時有哪些保護措施，以及企業為何決定通報或不通報。
舉例來說，涉及管理員密碼外洩的事件，未必能立即得知個人資料是否遭到存取。日誌應反映這種不確定性，記錄最初的疑慮、調查步驟、帳號活動審查，以及取得證據後的最終結論。
在這個階段，許多企業會專注於整理技術修復，卻忘了記錄法規遵循的判斷依據。密碼重設了、帳號安全了，營運也照常進行。幾週之後，企業卻無法說明當初為何認定該事件無須通報。
監管機關對記錄的期望
監管機關不只看資料外洩是否已通報，也可能會詢問企業如何：
- 識別事件
- 評估風險
- 判斷是否需要通知
- 記錄所採取的行動
良好的記錄應能從頭到尾清楚呈現事件的來龍去脈，說明發生了什麼事、涉及哪些個人資料、可能造成什麼損害、企業採取了哪些圍堵措施，以及為何通報或不通報這起資料外洩。
記錄的詳細程度應與事件的嚴重程度相符。誤寄電子郵件不需要與勒索軟體攻擊相同的記錄，但仍須加以記錄，以顯示企業已妥善評估。
這些記錄也應安全儲存。事件日誌可能包含受影響當事人、受影響系統、員工行動、螢幕擷取畫面、存取日誌或補救步驟等敏感詳細資料。存取權限應僅限於需要的人，保留期限則應符合公司更廣泛的資料保留政策。
憑證存取日誌
許多事件都與憑證有關：可能因密碼重複使用、共用帳號、收件匣遭入侵、管理員登入資訊外洩、可疑的 MFA 提示，或員工未妥善完成離職程序而引發。
因此，憑證存取記錄可直接做為資安事件文件的輸入資料。當事件涉及共用登入資訊或敏感帳號時，企業必須知道誰擁有存取權、存取權如何共用、權限是否變更，以及事件後是否已更換憑證。
像 Proton Pass for Business 這樣的企業密碼管理程式，可協助團隊在加密保管庫中管理憑證、產生專屬密碼、使用自動填入、安全地共用憑證、管理通行密鑰，以及使用內建的雙重身分驗證。就事件記錄而言，最大的價值在於憑證的存取軌跡：誰有權存取共用的保管庫／帳號、存取權如何管理與由誰使用，以及事件後有哪些變更。
適合 IT 團隊的密碼管理程式新增了管理員功能，例如政策、報告、日誌、以角色為基礎的存取控制、SCIM 佈建，以及 SSO 整合。這些功能可協助企業顯示憑證存取如何受到控管，並在調查憑證相關事件時提供佐證。
密碼管理程式無法取代事件日誌、法律評估、法規通知流程或事件應變計畫，但能提供可納入這些流程的憑證佐證。
使用企業密碼管理程式，保留完整的憑證存取稽核軌跡。
