事故處理要能更趨近完美，必須仰賴最早期的事前準備、專業的團隊，以及足夠的資源等綜合因素的整體配合。本文雖僅著重在資訊安全事故處理方面，但其中有許多觀念，同樣也適用於企業事故處理或營運持續管理等方面的應變步驟。
其實要執行初步分析和核實並不如想像中簡單，因為要掌握許多基本資訊，如果在日常作業沒有做好基本功的話，分析對你而言甚至會是連想都不用去想的事情。下面是對於讓事故分析更簡單和更有效的一些建議：
對網路和系統剖繪
剖繪是為了找出各種特徵的基準值，這樣一來，在發生變化的時候，會比較容易找出變化所在。剖繪的範例像是執行檔案完整性檢查軟體去找出重要檔案的Checksum、監控網路頻寬使用量以便判斷所謂的不同天之平均使用量和尖峰使用量。實務上，想要採用大多數的剖繪技巧來準確偵測事故，也不見得那麼容易；組織對於剖繪的態度，應該是要看待成眾多偵測和分析方法的其中一種，而非全部依賴剖繪。
了解正常行為
事故回應團隊的成員應該要去研習網路、主機系統、應用系統以了解何謂正常行為，這樣的話，在非正常行為發生的時候才比較容易判斷。不可能有事故處理者可以精通各種環境的行為，但是事故處理者應該要知道哪一個專家可以來彌補這塊專業性的落差。當然，Log紀錄和安全警告可能也會透露一些基本資訊。還有，如果沒好好利用過濾器去把Log限縮到合理的大小的話，那麼要檢視這些東西必定就是個無聊又枯燥的事情。
隨著事故處理者變得更熟悉這些Log和警告，他們應該要能夠花更多時間專注在無法解釋的紀錄上，而這通常也是更需要去調查的東西。常常檢視Log的人應該要保持知識更新，而且分析人員應該要能夠注意趨勢以及隨著時間的各種改變。
打造Log保存政策
事故的各種相關資訊可能會被記錄在許多地方，例如防火牆、IDPS、應用系統的Log。建立並實施Log保存政策去明確指出Log資料應該要維持多久，可能在分析時特別有幫助，因為老舊的Log紀錄可能會顯示出偵查活動或先前的類似攻擊紀錄。
另一個理由是，已經有許多過往案例和研究報告指出，資安事故被發現的時候，通常都已經過了好幾天、甚至好幾個月。到底Log資料應該維持多久？這與許多因素都會互相拉扯，包含組織本身的資料保存政策、擁有多少資料量、有多少預算可以用在資訊基礎建設等因素。
將事件關聯化
事故的各種證據可能是散落在各種Log裡面，而這些資料種類又都不同：防火牆Log可能有來源IP，而應用系統Log可能有使用者帳號名稱。Network IDPS可能偵測到攻擊是針對特定的主機，但可能不知道該攻擊是否成功。分析人員可能需要檢查主機的Log以判斷該資訊的前因後果。如果你的心態是想要去把這些各種跡象的事件兜起來去證明真的有事故發生，那其實可以先做好無功而返的心理建設。
保持所有的主機鐘訊同步
有些通訊協定（例如NTP）就是負責鐘訊同步。如果設備通報的事件彼此的鐘序都不同，那只會讓你做起事來更無力而已。從證據的角度來說，當然是彼此的Log都有一致性的時戳是比較好的。
打造並使用知識庫
知識庫應該包含那些在事故分析過程中可以讓事故處理者快速參考的資訊。雖然打造出來的知識庫有時候比較沒有結構性，但如果可以讓使用者比較有效率地檢索到想要的資訊，當然是更好的。
文字紀錄、試算表，以及相對簡單的資料庫，其實都可以給團隊成員提供有效、具有彈性，而且可以搜尋的方式。知識庫應該也要包含多樣化的資訊，包含對於徵兆和跡象的重要性與可信度的解釋，例如對於IDPS的警告、作業系統的Log、應用系統的錯誤代號等的解釋。
執行封包側錄以收集額外資料
有時候跡象並未記錄足夠的細節，讓事故處理者了解到底發生甚麼事情。如果網路上正在發生一個資安事故，收集必要資料的最快方法可能就是取得封包側錄所擷取的網路流量。將封包側錄器設定成去記錄符合特定準則的網路流量，也應該要儘量將資料量維持在一個可以管理的程度，而且盡可能將不小心的錯誤最少化。如果考慮到隱私權議題的話，某些企業可能會要求事故處理者在開始封包側錄之前去取得相關同意書。
過濾資料
實務上，要去檢視並且分析全部的跡象也不可能有那麼多時間。但最少，應該是著手去調查最可疑的活動。其中一個策略就是把看起來不重要的跡象給過濾掉，而另一個策略就是只呈現有最高重要性的跡象。當然，如果選擇後者的方式，可能會帶來另一種高風險，因為其中參雜著新型而不自知的惡意活動直接就被忽略了。
事故紀錄
如果事故回應團隊認定有事故已經發生，就應該立即開始記錄關於事故的所有事實。日誌紀錄本（Logbook）是個有效而且簡單的媒體，但是筆電、錄音器、數位相機也都可以達成這個目的。記錄系統事件、通訊，以及被觀察到的檔案變更都可以帶來更有效、更系統化、較不容易出錯的過程和結果。從偵測到事故一直到最終解決了的整個過程中，每個採取的步驟都要被記錄起來並且賦予時戳。每個關於事故的文件應該要給予日期，並且由事故處理者簽名。這種資訊也可以拿到法庭上當證據。如果可能的話，事故處理者所工作的團隊至少還要有另外兩種人：其中一種負責記錄並且Log事件，另一種負責執行技術任務（但實際上會因為組織的編制、規模、預算等各種因素而導致不同的團隊能量）。事故回應團隊應該要記錄事故現況，伴隨著其他適當的資訊一併記錄。採用應用系統或資料庫，例如議題追蹤系統，可以協助確認事故已經被著手處理並且有及時地被解決。這樣的議題追蹤系統應該包含下列資訊：