インシデント管理プロセスには、主に以下の6つの活動があります。

1. 受付と記録の実施
顧客からの問い合わせの全ての記録を行います。

2. 分類と優先度付けの実施
インシデントに「誰が対応すべきか」、「どのように対応すべきか」、「どれだけ急いで対応すべきか」、「すぐに解決できそうな問題か」など、対応に必要な基礎情報を特定するため、「インシデントの種類（障害回復要求／サービス要求、情報照会）」、「障害がもたらす影響の対象と範囲」などに基づいて、インシデントの分類を行います。

3.ファーストヘルプラインによる解決
分類結果に基づき、対応が容易なもの（例：単なる情報照会や対応手順が決まっている問い合わせ、過去に発生したことのある事象（既知の問題）など）については、ナレッジベースなどを活用しつつ、ファーストヘルプラインによる解決を試みます。

4. エスカレーションによる解決
ファーストヘルプラインにより解決できなかったインシデントや、あらかじめ定めた基準を超える内容のものについては、サービスレベルアグリーメント（SLA）の制約の範囲内で、適切にエスカレーション（より詳細かつ正確な調査・判断ができるスペシャリストへ依頼する）し、調査し、解決を図ります。

5. インシデントの追跡とライフサイクル管理
インシデントの担当者は、報告を受けたインシデントがクローズされるまでの間「インシデントの報告を受けてからの経過期間」「現在の調査状況」「顧客へのアップデート状況」「次回の進捗報告のタイミング」「解決が長引いている場合のエスカレーションの必要性」などについて管理を行います。

6. クローズ
インシデントが解決された時点で、顧客ならびに関係者に速やかな報告を行います。また、解決にいたった活動について記録を行います。

インシデント管理が、あくまでも顧客へのITサービスをいかに迅速に復旧させるかを目的としているのに対し、「問題管理」は原因究明を目的しています。

以下を例にとり解説します。

【顧客からの報告内容】
「サーバがソフトのバグによりシステムダウンしてしまった」

【IT部門が行った4つの活動内容】

1. 「サーバの再起動を行ったところ、ソフトが再び稼働した」（回復処置）
2. 「モジュールにバグを発見したためパッチを作り2日後に適用した」（是正処置）
3. 「同様のモジュールを使用しているソフトが他にも多数あることが判明したため、後日それらにもパッチを適用した」（予防処置）
4. 「バグが発生した原因が、開発時のQA（Quality Assurance：品質保証）プロセスのチェックの甘さにあったことがわかり、QAで使うチェックリストの改善を行った」（是正処置）

「IT部門が行った4つの活動内容」のうち、1番にあたるものが「インシデント管理」によるものです。そして、2、3、4番が「問題管理」によるものです。ただし、場合によっては障害復旧のための（インシデント管理における）活動が、イコール、原因究明につながるケース（上記の例で言うところの2番も同時に行える場合）もあります。とは言うものの、問題管理は上記の例で言うと2番だけでなく、3番や4番などに対する管理も行う必要があることから、厳密にはインシデント管理と分けてプロセスを考えることが必要になります。

先述したとおり、インシデント管理はIT運用管理プロセスの1つであり、ITサービスの利用者（顧客）が”何らかの理由により”業務を遂行できな状態を、いかに早く解決し、業務を続けられるようにするかを支援することを目的とした活動を指します。

これに対し、サービスデスクは機能の1つであり、顧客とIT部門とを密につなぐことを目的とした活動を行う組織（人の集まり；単一窓口）を指します。なお、顧客とIT部門とを密につなぐことを目的とした活動とは、たとえば、
 

• インシデント管理における初期サポートやエスカレーションに関わる活動
• 新しいプログラムリリースについての顧客への案内
• 顧客満足度調査の実施
• 傾向分析（合意された期間内に解決したインシデントの割合や放棄呼率※2の分析）結果などからのサービス改善提案の実施

などがあります。サービスデスクは、これらの活動を行う組織全体（”機能”）を指します。

インシデント管理は、変更管理と同様に「ITガバナンス」、「ITの運用管理」、「情報セキュリティ」のいずれにおいても中核を担うコントロールになります。

以下に、代表的なインシデント管理の位置づけについて挙げておきます。

インシデントという言葉は、非常に抽象的な意味を持つため、対象とする規格・ガイドライン・組織・人によって解釈が異なる可能性が高いものです。実際、インシデントは「出来事」という意味で日本語に訳されます。その語源を見てみても、インシデント（＝incident）は"in-cidere"に由来し、これはすなわち"on" + "to fall"であり、「何らかの結果に何とはなしに結びつく事象のこと」と示されます。

このことからも、「インシデント＝システム障害」と、必ずしも単一的に結びつくものではないことが分かります。したがって、「インシデント管理」において重要なことは、自分たちの組織に導入しようと考えている管理のプロセスにおける”インシデント”とは何であるのか？ということを真っ先に確認・定義することであると言えます。