サービスの標準の運用に属さないイベントであり、サービス品質を阻害、あるいは低下させる、もしくはさせるかもしれないあらゆるイベント
これがサービスサポートで示されているインシデントの定義です。しかし、サービスサポートをよく読んでみると、ITIL におけるインシデントの定義は非常に複雑であることを発見します。 インシデントの定義には、２つの例外があります。
まず最初の例外は、サービス要求をインシデントとしている点です。ハインリッヒの法則で定義されているインシデントは「事故を引き起こす可能性がある事象」なのですが、 インフラストラクチャの障害とサービス要求は対応が類似しているために、ITILでは サービス要求もインシデントの一種と見なしています。このことは、消耗品の交換など通常の業務と見なされる事象もインシデントに含まれることを意味します。
もう一つの例外は１６９ページ（変更管理の章）で述べられているように、パスワードやサービス時間の一時的な変更まで変更要求として管理すると、サービスサポートの全プロセスへの負荷が大きくなるので、変更管理が無視できる変更の要求をサービス要求としている点です。
（逆の言い方をすれば、パスワードや一時的なサービス供給時間は構成アイテムやその属性として扱わないということです。）
以上のことをまとめると、インシデントは次のどちらかになります。
（変更管理が関与せずに効率的に管理できる変更の要求を含む）
私はこの結論を得るために、サービスサポートを何度も読み返さなければなりませんでした。サービスサポートの７１ページには次の様な記述があります。
『この章（インシデント管理の章）で説明する「インシデント」は、 特に明記されない限り、インシデントと変更要求(RFC) の両方を示す。』
しかし原文には「変更要求」という言葉はどこにも見当たりません。
『The word 'Incident' in this chapter applies to both, if not explicitly stated otherwise,...』
つまり、インシデント管理の章に出てくる「インシデント」がインシデンと変更要求と明記されているわけではなく、単に「両方」と 書かれているのです。そしてこの「両方」をインフラストラクチャの障害とサービス要求と解釈した方が、むしろ 全体として整合性のある以下のような文章に落ち着くのです。
『この章で説明する「インシデント」は、 特に明記されない限り、インフラストラクチャの障害とサービス要求の両方を示す。』
