事故處理要能更趨近完美，必須仰賴最早期的事前準備、專業的團隊，以及足夠的資源等綜合因素的整體配合。本文雖僅著重在資訊安全事故處理方面，但其中有許多觀念，同樣也適用於企業事故處理或營運持續管理等方面的應變步驟。
‧事故現況（全新的事故、處理中、送往司法部門調查，或者已經解決等狀態）
‧事故總結
‧事故相關的跡象
‧與本案相關的事故
‧本案中所有事故處理者採取的行動
‧證據鏈（如果適用的話）
‧事故的衝擊分析
‧各方聯絡資訊（例如系統擁有者、系統管理者）
‧在事故調查過程中收集到的證據清單
‧從事故處理者而來的相關評論意見
‧後續要採取的動作（例如重建主機、更新應用系統）
再來，事故回應團隊也應該保全事故資料並且限制相關的存取行為，因為它通常會包含敏感資訊。舉例來說，應該要只有那些被授權的人員才能存取事故資料庫。事故溝通（例如E-mail）和文件也應該要被加密，不然就要用其他方式保護，這樣才能確保只有被授權人員才得以存取。
資安事故優先序
再來要談談，如果遇到同時要處理多個資安事故的時候，最重要的決策因素可能是要如何排定這些資安事故的順序。處理事故不建議用先到先處理（First-come, First-served，FCFS）的模式，而是應該依據像是下列這些相關因素來排定優先順序會比較恰當：
事故對營運帶來的衝擊
受遭殃的這些資訊科技系統通常都會衝擊到相對應的部門或企業營運功能，而給系統的使用者帶來某些負面衝擊。事故處理者應該考量該事故將會如何衝擊現行的功能。事故處理者除了考慮現行受到衝擊的功能外，也要留意到如果該資安事故未立即被封鎖起來的話，可能會在未來帶來更進一步的衝擊。（但如果遇到大規模的資安事故，可能光要對外說明或者應付媒體的時間就不夠，而實際情況也不容許一一去解釋真實的細部情況。所以有時候可能會先做最壞的打算，把所有可能的損失都暫時納入，等到分析調查完畢之後再正式公告實質的影響）
事故對資訊帶來的衝擊
事故可能會影響組織的機密性、完整性、可用性。舉例來說，惡意的代理人可能會把敏感資訊外洩。事故處理者應考慮這樣的資訊外洩將會如何衝擊組織的整體營運目標或宗旨。也應該意識到，資訊外洩甚至可能同時外洩企業的合作夥伴的相關資訊。
從事故中復原的能力
事故的規模和事故影響的資源種類，會決定要花多少時間和資源來復原該事故。在某些案例中，事故本身已經無法復原（例如敏感資訊的機密性已經被滲透），而且如果花有限的資源而導致事故處理所需時間更久的話，這樣反而意義不大；除非這是來自上層的指示，那或許就另當別論。在其他案例中，處理事故所需的資源遠超過組織所擁有的資源（例如近年來屢破紀錄的DDoS攻擊流量幾乎已經超過絕大部分組織自身的應付能力），所以必要時，記得尋求外部的協助。
把對於系統功能的衝擊和對於組織資訊的衝擊兩者整併在一起，可以決定該事故造成的營運衝擊。舉例來說，DDoS對於公開的網頁伺服器可能會暫時性地減少該系統功能，然而未經授權的高權存取卻可能導致個人資料或敏感資料外洩，這可能就會對組織聲譽造成長久性的衝擊。
至於，團隊對於事故的復原能力，則幾乎決定了團隊可能採取的回應。如果有那麼一種事故對企業功能造成高度衝擊，但團隊手邊有一種解決方案可以將事故快速復原而且成本不高，這當然是個很理想的。然而，某些事故可能沒有很順暢的復原管道，並且可能需要排隊等待在一個更高層的決策回應之後才能被分配到一些少得可憐的資源。
舉例來說，某駭客組織已經導致公司資料外洩並在某論壇公開張貼了以GB等級計算的的敏感資訊，這樣的話，根本也不用去想著要復原，因為資料早已經被暴露了。在這種情況下，該資料外洩事故的部分責任自然而然地移轉給高層，而不會只有事故回應團隊一肩把責任扛下。所以，團隊應該要依據估計出來的營運衝擊來排定回應的優先順序。
將事故所投入的努力給量化、資訊衝擊種類、恢復能力都判定出來之後，才比較容易向上級反映並且爭取相關資源。企業可以利用本身的認知，把對於事故所投入的努力給量化。表1是資安事故對於企業功能衝擊的分級，企業可能會採取這樣的分級方式來替資安事故分級。此外，事故分級也可以替企業將有限資源做出較佳的配置。
表2呈現的範例是關於可能的資訊衝擊種類，這些種類用來描述事故中資訊被滲透的程度。
表3呈現了恢復能力的種類，也反映了所需的資源種類。
另外，組織也應該要打造事故升級管理的流程，以用於當團隊無法在指定的時間長度內回應事故的時候。事故升級管理的流程，應該要載明事故處理者對於回應最長應該要等多久，又如果沒有任何回應的話，事故處理者應該採取甚麼樣的動作。