「変更管理」の導入では、以下の点について自社の特性を考慮しながらルール化を進めていくことが必要になります。

• アセスメントはどうするのか？
• 承認はどうするのか？
• 実装はどうするのか？
• レビューはどうするのか？
• 緊急事態における変更はどうするのか？

「アセスメントはどうするのか？」とは、変更がITサービスにもたらす効果やリスク、リスクが健在化しないための予防策、不幸にもリスクが健在化してしまった際の対処策など、どのような要素に基づいて誰がどうやって変更の妥当性について評価を行うのか、ということです。

「承認はどうするのか？」とは、誰からのどのような申請に基づいて、誰がどのような判断基準で、変更実施を許可するのか、ということです。

「実装はどうするのか？」とは、変更の承認がおりた変更内容について、誰がどのような手続きで、実際に変更を行うのか？ということです。

「レビューはどうするのか？」とは、変更した結果について、その変更した内容が当初の予定通りに行われているかどうか（検証）や、変更した結果もたらされた効果が期待していたものと同じであったかどうか（有効性の確認）といったことを、誰がどのように行うのか？ということです。

「緊急事態における変更はどうするのか？」とは、システムダウンによりお客様に明らかに迷惑がかかっている際のインシデント対応など、対応のスピードが要求される場面においての手続き（例：申請手続きの簡素化を許可する）ということです。

変更管理と混同されがちなリリース管理は、ともに”何らかの変更を加える”という点では同じですが、その対象が異なります。前者が「ITサービスに影響をあたえる可能性のある全ての変更」を対象としているのに対し、リリース管理では「本番環境への変更」を対象としています。言い換えると、リリース管理は「ソフトウエア（およびそれに伴うハードウェアや新しいマニュアルなどについて）の本番環境への移行」を前提とした際の手続きについて定めるプロセスであるということができます。

つまり、どのような場合でもITサービスへ何らかの変更を加える場合には、まずは「変更管理」にもとづく変更の承認を受ける必要がありますが、さらにこの変更が本番環境への変更を伴う場合に関しては、その具体的な進め方について「リリース管理」に基づく準備作業や移行作業、文書化作業などを行う必要があります。

変更管理は、「ITガバナンス」、「ITの運用管理」、「情報セキュリティ」のいずれの考え方においても極めて重要なコントロールとして位置づけられています。

以下に、代表的な規格における変更管理の位置づけについて挙げておきます。