事故處理要能更趨近完美，必須仰賴最早期的事前準備、專業的團隊，以及足夠的資源等綜合因素的整體配合。本文雖僅著重在資訊安全事故處理方面，但其中有許多觀念，同樣也適用於企業事故處理或營運持續管理等方面的應變步驟。
綜觀電腦科學及網路發展，資安事故已經從單一台系統遭殃、演變成網路型態的事故、再演變成應用系統的共同漏洞事故，而如今，不論流量規模、資源消耗的規模、受遭殃的主機或應用系統數量規模、或共犯組織規模，都朝著更大規模的事故在演化著。由此可知，資訊安全事故回應（Cyber Security Incident Response）變得愈來愈重要，甚至已經變成組織營運表現的其中一環。網路相關的攻擊愈來愈多且多樣化、更具破壞性，新型態的資安事故也不斷浮現。
即便根據風險評估結果所採取的預防性作為，或許可以降低事故數量，但實際上仍無法預防所有事故的發生。因此，事故回應（Incident Response）能力對於組織而言是必備的，藉以快速偵測事故、將損失和破壞最小化、並且復原資訊服務。
事故回應流程包含多個步驟。最開始的步驟涉及了建立並且訓練一個事故回應團隊，並且取得必要的工具和資源。在事前準備期間，組織也會嘗試著要限制未來會發生的事故數量，透過選擇並根據風險評鑑的結果實施一系列控制措施。然而，在實施控制措施之後，殘餘風險仍會不可避免地持續著。所以，可以藉由偵測到相關事件來警告組織資安事故發生了。
透過封鎖事故並且最後復原該事故，組織可以減緩資安事故所帶來的衝擊。在這個階段，通常會在偵測並分析事故這兩步驟來回交替。舉例來說，當我們在排除惡意軟體事故的時候去檢查看看是否有額外的主機有感染惡意軟體。在處理完資安事故之後，組織會發佈一份報告，內容詳細描述肇因、事故的相關投入與成本，以及組織為了預防未來再度發生而應當採取的步驟。
事故回應的流程包含了事前準備、偵測與分析、封鎖、排除、復原、善後等。本文章描述偵測與分析的其中一部分，針對資安事故分析、記錄、排定順序與通報進行闡述。本文章適合的讀者群有資安事故回應團隊、系統管理者、網路管理者、技術支援人員、資安長、資訊長，以及負責處理資安事故的相關人員。
事故分析
如果日常營運所得知的每個徵兆（Precursor）和跡象（Indicator）都有被保證是正確的話，那麼要偵測和分析事故其實可以很簡單。不幸地，現實生活中並非如此。舉例來說，使用者提供的跡象可能是他無法取得伺服器的服務，通常不見得完全正確，而IDS也可能產生錯誤的跡象。
這樣的例子就足以說明了事故偵測和分析為什麼不見得是一件容易的事：理想上，每個跡象應該被評估來判斷是否合乎常理。但光跡象的總數量每天可能數以千計或數以百萬計，就足以令人崩潰，若要從這裡面去找出真正已經發生的資安事故，概念上就如同海底撈針。而且就算跡象是正確的，也不完全表示事故真的發生。某些跡象例如伺服器當機或某些重要檔案被修改，這樣的原因並非資安事故。
然而，如果從發生的跡象去推測事故可能正在發生並且做出相對應行為，就比較合理。當我們要決定特定事件是否就是資安事故，有時候就只是一種判斷上的問題，可能要與其他技術人員或資安人員交換意見之後才能下決定。
在許多案例中，儘管事件本身不一定與安全有相關，但都應該被處理好。舉例而言，如果一家公司正在經歷每12個小時就要網路斷線一次，但沒人知道確切原因，那麼人員可能會想要儘快解決這個問題，不管它的原因是甚麼。
如果稍微思考一下，就不難理解為什麼某些事故很容易偵測到，例如明顯的網頁置換（這在某些國際知名的平台上有許多駭客組織將網頁置換當作練兵場，有時候也可以去這些地方找看看自家的網站是否已經遭殃）。然而，許多事故並不見得有如此明顯的症狀。小小跡象，例如一個系統內組態設定檔案的改變，可能是發生事故的唯一跡象。而當我們說，偵測可能是事故處理當中最困難的任務，是因為事故處理者要去分析模糊、有矛盾的甚至是不完整的各式各樣的現象才有辦法判斷到底發生甚麼事情。
雖然有技術上的解決方案可以讓偵測這件事情比較簡單，但最好的上策還是要打造一個團隊，擁有高度經驗、高度專業的人員，可以有效且有效率地分析徵兆和跡象，並快速採取適當作為。
如果人員缺乏訓練或經驗能力的話，事故分析和偵測做起來不僅沒效率、甚至可能會錯誤百出。
事故回應團隊（IRT）應該迅速去分析並核實各個事故，緊跟著預先定義好的流程並且記錄所採取的每個步驟。當事故回應團隊確定事故真的發生了，就應該要快速執行初步的分析來判斷事故的範圍，例如哪一個網段、系統主機或應用系統被影響、由誰或由哪一個元件所導致，以及該事故到底如何發生的（例如對方用甚麼工具或攻擊手法、甚麼漏洞被利用了）。初步的分析，應該提供足夠資訊給團隊去排定接下來要採取的行動的優先順序，例如將事故封鎖以及深度分析該事故的影響。