内部統制評価の中でも、IT統制に対し、苦手意識を持っている内部監査部門のご担当者様も多いようです。そのため、どのようにIT統制の評価を行うのか分からないという声を聞くこともあります。IT統制の評価については、情報システム部門に任せきりになっているという企業様もいらっしゃるようです。
内部統制の評価は本来、独立的な組織体である内部監査部門で行うべきです。
そこで、今回はIT統制の評価方法について、見ていきたいと思います。
IT統制評価のポイント
IT統制の評価を行うにあたり、まず押さえておくべき点としては、あくまでも『統制』の評価であるということです。
IT統制の評価を行う上で、システム開発の言語やITインフラの知識等、ITに係る詳細な経験や知識は必要ありません。
内部統制の評価を行う上で必要なことは、「業務プロセス」と「リスク」を把握し、「コントロール」や「評価ポイント」を理解することです。
今回は、IT全般統制の中の『システム開発』・『システム変更』に関する「業務プロセス」「リスク」「コントロール例」「評価ポイント」を説明します。
なお、IT統制の評価方法については、以下も参照してください。
内部監査部門の泣き所！IT統制を克服するためのポイント
IT全般統制：システム開発のプロセス
まず、『システム開発』におけるプロセスの内容を見ていきます。
システム開発は、一般的には以下のようなステップで進めていきます。
①企画・選定
業務のニーズに合うシステムを検討・選択します。システムのユーザ部門（例：会計システムであれば、経理部等）の要望に基づき、システム部門と連携しながら、どのようなシステムを導入するかを検討します。
②要件定義
システムに必要な機能を決定し、システムの仕様を決めていきます。
ユーザ部門が業務を行う上で、システム上どのような機能が必要かを定義します。
③システム設計
要件定義で決定した仕様に基づき、システム部門ないしITベンダーにて、どのようにシステムを設計するかを策定します。
④システム開発・導入
システム設計に基づき、システムの開発ないし導入を行います。
いわゆる、プログラミングや設定を行うものになります。
⑤テスト
要件定義に沿った形で、システムが開発されているかをテストします。
テストは、システム部門ないしITベンダーが実施した上で、システムのユーザ部門でも行う必要があります。
⑥本番移行
開発したシステムが問題無いことを確認した後、過去の本番データを新システムに移行し、システムを利用するための準備を行います。
システム部門が中心となりますが、システムの企画や要件定義はユーザ部門が主管となります。
開発したシステムのテストは、ユーザ部門でも行います。
IT全般統制：システム開発の評価ポイント
次に、システム開発におけるリスク及びコントロール、評価ポイントについて、ステップ毎に見ていきたいと思います。
①企画・選定
（想定されるリスク）
ニーズに合ったシステムが構築できず、業務が機能しない
（コントロール例）
選定結果を稟議書に添付・回覧し、決裁者が承認する
（評価ポイント）
選定結果に対する記録が保管されており、決裁者の承認が行われていること
②要件定義
（想定されるリスク）
意図したシステムに開発されず、適切に利用できない
（コントロール例）
作成した要件定義書を回覧し、ユーザ部門が承認する
（評価ポイント）
要件定義書が作成されており、ユーザ部門の承認が行われていること
③システム設計
（想定されるリスク）
要件通りのシステムが構築できず、安全性が確保できない
（コントロール例）
システム設計書を作成し、システム部門長が承認する
（評価ポイント）
システム設計書が作成されており、システム部門の承認が行われていること
④システム開発・導入
（想定されるリスク）
適切に開発・導入が行わないと、不正や誤謬のリスクがある
（コントロール例）
開発完了を報告し、システム部門長が承認する
（評価ポイント）
関発完了の記録が保管されており、システム部門長の承認が行われていること
⑤テスト
（想定されるリスク）
要件を満たしているか確認できず、安全性が確保できない
（コントロール例）
要件定義に則り、テストを実施し、ユーザ部門が承認する
（評価ポイント）
テストの実施記録が保管されており、ユーザ部門の承認が行われていること
⑥本番移行
（想定されるリスク）
適切な移行が行われず、正しい数値を担保できない
（コントロール例）
本番データの移行完了を報告し、ユーザ部門が承認する
（評価ポイント）
本番データの移行確認が行われており、ユーザ部門の承認が行われていること
システム開発の評価では、システム部門の承認だけでなく、ユーザー部門の承認が行われているかを確認します。
IT全般統制：システム変更のプロセス
続いて、『システム変更』におけるプロセスの内容を見ていきます。
システムの変更を行う際は、一般的には以下のようなステップで進めていきます。
①変更の依頼
業務の変更等に伴い、ユーザ部門からシステム部門へプログラムの変更を依頼します。
②変更の実施
システム部門にて、プログラム変更の要否を判断した上で、プログラムの修正を行います。
③変更のテスト
変更したプログラムの影響が無いか、依頼した内容に沿っているかをユーザ部門にて確認します。
④本番環境への移行
プログラム変更のテスト完了後、変更したプログラムを本番環境に反映させます。
⑤移行のテスト
本番環境への移行後、ユーザ部門にて変更したプログラムの影響が無いか、依頼した内容に沿っているかを確認します。
ユーザ部門からの変更依頼の要否を判断の上、システム変更を行います。
また、変更したシステムのテストについては、ユーザ部門でも行います。
IT全般統制：システム変更の評価ポイント
次に、システム変更のリスク及びコントロール、評価ポイントについて、ステップ毎に見ていきたいと思います。
①変更の依頼
（想定されるリスク）
不適切なシステム変更により、データの信頼性が失われる
（コントロール例）
変更申請書にて依頼を行い、ユーザ部門長が承認する
（評価ポイント）
変更依頼の記録が保管されており、ユーザ部門の承認が行われていること
②変更の実施
（想定されるリスク）
意図したシステムに変更されず、適切に利用できない
（コントロール例）
変更申請書に作業記録を記載し、システム部門長が承認する
（評価ポイント）
変更実施の記録が保管されており、システム部門の承認が行われていること
③変更のテスト
（想定されるリスク）
要件の充足や適否が確認できず、安全性が確保できない
（コントロール例）
変更申請書にテスト記録を残し、ユーザ部門長が承認する
（評価ポイント）
テスト実施の記録が保管されており、ユーザ部門の承認が行われていること
④本番環境への移行
（想定されるリスク）
不適切なプログラムが移行され、不正処理のリスクがある
（コントロール例）
変更申請書に移行記録を記載し、システム部門長が承認する
（評価ポイント）
本番環境への移行の記録が保管されており、システム部門の承認が行われていること
⑤移行のテスト
（想定されるリスク）
ユーザが意図した通りにシステムを利用できない
（コントロール例）
変更申請書に確認結果を記載し、ユーザ部門長が承認する
（評価ポイント）
本番環境への移行確認の記録が保管されており、ユーザ部門の承認が行われていること
システム変更の評価では、各ステップの記録（証憑）が作成・保管されており、承認記録が残っているかを確認します。
IT統制と聞くと、ITの詳細知識が必要ということをイメージしがちですが、評価ポイントとしては、記録が残っており、承認がされているという点になります。
「業務プロセス」と「リスク」を把握し、「コントロール」や「評価ポイント」を理解し、改めてIT統制の評価に取り組んでみてはいかがでしょうか。
IT統制評価のポイント
☑IT統制における「業務プロセス」と「リスク」を把握する。
☑「業務プロセス」と「リスク」を把握した上で、「コントロール」や「評価ポイント」を理解する。
システム開発のプロセスと評価ポイント
☑システム開発においては、システムの企画や要件定義についてはユーザ部門が主管となる。
☑システム部門の承認だけでなく、ユーザー部門の承認が行われているかを確認する。
システム変更のプロセスと評価ポイント
☑システム変更は、ユーザ部門からの変更依頼の要否を判断の上行われる。
☑各ステップの記録（証憑）が作成・保管され、承認記録が残っているかを確認する。
