Event Management Process 可以很簡單，譬如簡易的伺服器及應用系統 log 收集；當然也可以很複雜，詳如 ITIL V3 理論內容，它勾勒出完整的處理程序及流程，輔以不同狀態的子流程因應，以供有興趣之企業組織參考。
Event Management Process:
一、Event Occur, Notification and Detection
在服務設計階段，應儘量邀請各流程、角色參與討論，並針對"重要"區域及服務進行 Event 偵測及通報的機制，若預算許可，則應盡可能以自動化去收集並接受 Event 通知，降低人力維運成本。
二、Event Filtering
就管理而言，時間及能量要用在刀口上，許多 Event 需要偵測並記錄下來，但卻不一定都須進行後續的行動及審查，故在此階段活動，應制定出 Event 過濾的條件，針對不同等級的 Event 進行相對應的處置。
三、Significaces of Event
一般而言， Event 可分成三種等級：
(1) Informational：泛指不需進一步行動的事件，且不算是意外性質(exception)。
(2) Warning：某種事件之影響，已即將超過可接受門檻值(threshold)。
(3) Exception：代表某資訊服務之運行已不正常(abnormal)，通常而言，此類情形發生時，SLA 或 OLA 所承諾之服務等級已無法達成，可轉由事故管理或變更管理流程進行處置。切記，此類事件不完全等同於事故!
四、相對應子流程處理程序
(1) Informational Event => Event Logging => Action(if neccessary) => Event Clsoure.
此類事件較為單純，大多記錄後備查，若有必要則進行行動補強。
(2) Waring Event：
Warning 事件接收後，應進行 Event Correlation 事件關連性分析，若多個相似或相關連的 Warning Event 已產生，則可依情節嚴重程度區分，進行不同處置方法：
1. 情節嚴重者，則轉由 Incident or Change management processes 處理。
2. 情節適中，需進一步觀察者：發出 Alert 通知相關人員等，並視情況進行 Human Intervention 人為介入改善處理。
3. 常見情節者：則設計、建置自動修正處置(Auto-Response)。
(3) Exception Event：
轉由 Incident, Problem or Change management processes 處理。
五、Event Effectiveness confirm and Closure
事件改善處理後，應進行有效性確認 (Action effectiveness confirm)，若有效則可結案(Closure)；若無效，則重新導回 Incident, Problem or Change management processes.
