問題管理活動を行うためのトリガーには大きく分けて以下の2種類があります。

1. 過去に経験したことのないインシデントが発生したとき
2. 解決したはずの（類似した、または同一の）インシデントが再び発生したとき

1の「過去に経験したことのないインシデントが発生したとき」とは、文字通り、発生したインシデントが過去に経験したことのない障害で、根本原因を新たに探る必要があるようなケースを指しています。

2の「解決したはずの（類似、または同一の）インシデントが発生したとき」とは、過去に根本原因を特定し解決済みのはずなのに再び、同じようなインシデントに見舞われたときのことをさします。これはすなわち、特定したと思っていた根本原因が、実は、真の意味での根本原因でなかったか、または、それに対する解決策が正しく実行されていなかったことを意味するため、再度、真の根本原因究明のための活動（問題管理）が必要になるわけです。

1や2のトリガーとは別に、数件から何百件にわたる過去のインシデントを集めて分析してみて初めて見えてくるもの（傾向）がある場合があります。たとえば、過去に発生した100件のインシデントを障害原因別に分類することで、インフラストラクチャの物理的な故障に起因するものが数多く出ていることが判明したとします。この場合、インフラストラクチャで使用している機材の品質自体に何らかの問題があることが考えられます。

問題管理プロセスには、主に以下の4つの主要な活動があります。

1. 問題の記録・分類
問題の検出とそれら全ての記録を行うための活動で、先述したように、インシデントの発生をもたらした根本原因が不明な場合に、問題として認識されることになります。ここで問題が認識された時点で、発見された問題への対応し忘れを防ぐために、特定された問題の基礎情報（例：関連するインシデントの情報、問題の発見者など）について記録をしておくことが必要不可欠です。
2. 問題の調査・診断
「問題」として認識され、対応が必要なものが複数ある場合には、対応するリソースに限りがあることから、対応の優先順位付けを行う必要があります。ここで分類された優先順位にもとづき、より優先度の高い問題から、調査を開始し、根本原因の究明を目指します。
3. エラー制御
特定できた問題の根本原因について、実質的な解決策を施し、再発防止につなげます。
4. 問題のクローズ
問題を解決できた場合には、その対応結果を今後のナレッジベースとして活用するため、その問題の発生経緯や解決策など基本的事項を詳細に記録しておくことが重要です。このような記録を持つことにより、万が一、同じようなインシデントが再び発生してしまった場合でも、原因究明の手助けとなり、迅速な解決につながることになります。

繰り返しになりますが、インシデント管理があくまでも顧客へのITサービスをいかに迅速に復旧させるかを目的としているのに対し、「問題管理」は障害の原因究明を目的としています。また、インシデント管理がビジネスに対するITサービスの復旧を第一に考えているのに対し、問題管理はその根本原因を明確にし、解決と再発防止に重点を置いています。

では、具体的にどのような違いがあるのでしょうか。以下を例にとり解説します。

【顧客からの報告内容】
「サーバがソフトのバグによりシステムダウンしてしまった」
【IT部門が行った4つの活動内容】
「サーバの再起動を行ったところ、ソフトが再び稼働した」（回復処置）
「モジュールにバグを発見したためパッチを作り2日後に適用した」（是正処置）
「同様のモジュールを使用しているソフトが他にも多数あることが判明したため、後日それらにもパッチを適用した」（予防処置）
「バグが発生した原因が、開発時のQA（Quality Assurance：品質保証）プロセスのチェックの甘さにあったことがわかり、QAで使うチェックリストの改善を行った」（是正処置）
「IT部門が行った4つの活動内容」のうち、1番にあたるものが「インシデント管理」によるものです。そして、2、3、4番が「問題管理」によるものです。ただし、場合によっては障害復旧のための（インシデント管理における）活動が、イコール、原因究明につながるケース（上記の例で言うところの2番も同時に行える場合）もあります。とは言うものの、問題管理は上記の例で言うと2番だけでなく、3番や4番などに対する管理も行う必要があることから、厳密にはインシデント管理と分けてプロセスを考えることが必要になります。