目次
1. ITコントロールの分類と評価アプローチ 2. 一般ITコントロール(GITC)のテスト手続 3. 業務処理コントロールのテスト手続 4. 実例による検証手続 5. 監査人が確認するドキュメント 6. よくある不備と対処法 7. 実務チェックリスト
ITコントロールの分類と評価アプローチ
ISAE 3402.A73は、ITコントロールを2つの層に分けて評価するよう求めている。第一層がGITC、第二層が業務処理レベルのアプリケーションコントロール。この分層アプローチは単なる整理手法ではない。GITCの不備は、その上に構築される全ての業務処理コントロールの信頼性を損なう。基礎が崩れれば上物も崩れる。
監基報315.21は、ITの利用が広範囲にわたる場合、IT環境の統制を理解することが内部統制全体の評価に直結すると述べている。サービス組織において、ITは単なるツールではなく、コントロール環境そのもの。
GITCの評価は、業務処理コントロールの評価に先行しなければならない。GITCに大きな不備があれば、アプリケーションレベルのコントロールが設計通りに機能していても、その有効性は著しく制限される。アクセス管理が甘ければ、承認プロセスのコントロールは機能しないだろう。
設計有効性と運用有効性の区別
ISAE 3402.57では、各コントロールについて設計有効性と運用有効性を別々に評価することを求めている。設計有効性は「コントロール目標の達成に対して妥当に設計されているか」を問い、運用有効性は「期間を通じて機能し続けたか」を問う。二つは別の問いである。
設計有効性の評価は、コントロールの手順書、システム設定、承認フローの確認を通じて行う。運用有効性には、実際の取引サンプルを使った詳細テスト、例外事項の分析、自動コントロールの継続的運用の証拠が必要となる。
一般ITコントロール(GITC)のテスト手続
アクセス管理のテスト
アクセス管理は全てのITコントロールの基盤となる。ISAE 3402.A74は、論理アクセス制御について以下の要素の評価を求めている。新規アクセス許可の承認プロセス、定期的なアクセス権の見直し、異動・退職時のアクセス削除、特権アクセスの管理。この4要素を漏れなく検証する。
新規アクセス許可のテストでは、テスト対象期間中に付与された全アクセス権から、リスクベースでサンプルを選定する。各サンプルについて、申請書、承認者の署名、システム管理者による実行記録を確認。承認者が申請者の職務内容を理解し、必要最小限のアクセス権のみを承認しているかを検証する。
定期的レビューのテストでは、四半期または半年ごとのアクセス権棚卸しプロセスを確認する。部門管理者による承認記録、アクセス権の削除実績、レビュー対象から漏れたアカウントの有無を検証。特に長期間使用されていないアカウント(通常90日以上非アクティブ)の処理状況は重点確認ポイントだ。
変更管理のテスト
変更管理は、システムの整合性とコントロールの継続性を確保する統制である。ISAE 3402.A75は、システム変更について妥当な承認、テスト、実装の手続が整備されていることを求めている。
テスト対象期間中の主要なシステム変更を特定し、各変更について以下を確認する。変更要求の記録と承認、開発環境でのテスト実施記録、本番環境への移行前レビュー、移行後の検証結果。緊急変更については、事後承認と追加レビューのプロセスも確認対象となる。
バックアップ・災害復旧のテスト
データの完全性と可用性を確保するコントロール。バックアップの定期実行記録、復旧テストの実施状況、オフサイト保管の証跡を確認する。監基報315.A126は、IT環境における業務継続性についてその意義を述べている。
年次の災害復旧テストについては、テスト計画書、実施記録、発見された課題と改善措置を詳細に確認する。テストが形式的なものではなく、実際の業務継続に必要な機能を検証しているかを評価する。本音を言うと、「テストしました」という報告書だけ出てきて中身が空っぽのケースは少なくない。
業務処理コントロールのテスト
自動コントロールのテスト
自動コントロールは、一度設定されれば継続的に機能する。ただし設定の正確性と継続的運用の証拠が必要となる。ISAE 3402.68は、自動コントロールについて、設定の正確性、変更に対する統制、例外処理の妥当性を確認することを求めている。
計算ロジックの検証では、主な自動計算(利息計算、手数料計算、税額計算等)について、システムに組み込まれた計算式と業務要件の一致を確認する。テストデータを使って独立再計算を行い、システム出力との一致を見る。ここでズレがあれば根本原因の特定に進む。
例外処理の確認では、システムが検知したエラーや例外事項について、担当者への通知、調査・修正プロセス、承認者によるレビューが機能しているかを見る。例外レポートの完全性(全ての例外が含まれているか)も見逃せない検証ポイントである。
手作業コントロールのテスト
手作業コントロールは人的要素が関与するため、より多くのサンプルテストが必要になる。ISAE 3402.A86では、手作業コントロールの性質と頻度に応じたサンプル数の決定を求めている。
日次コントロールは年間を通じて20~25サンプル、週次は15~20、月次は8~12が一般的。各サンプルについて、実行者の署名、実施日時、発見された例外事項とその処理状況を確認する。
データ完全性のテスト
データの完全性と正確性を確保するコントロール。インターフェイス処理における件数チェック、金額合計の照合、重複データの検知・除去プロセスを確認する。
月次の残高照合プロセスについては、照合の実施記録、差異の調査・修正プロセス、承認者によるレビューを詳細に確認する。未解決の差異がある場合は、その内容と管理状況の評価が必要だ。
実例による検証手続
田中ロジスティクス株式会社、物流サービス業、売上高約128億円、従業員約850名。
田中ロジスティクス社は、全国15箇所の物流センターを統合する基幹システム「LogiNet」を運用している。各センターからの出荷・入荷データをリアルタイムで本社システムに集約し、顧客企業への請求処理を自動化している。
ITコントロールの識別と評価
LogiNetシステムの分析により、以下のコントロールを識別した。
1. アクセス管理(リスク度:高) - 新規アクセス申請の3段階承認(申請者上司→IT管理者→システム管理者) - 月次のアクセス権棚卸し(各部門長による確認) - 退職者アクセス削除の即日実行
調書ノート:コントロール設計書にアクセス管理フローとサンプル帳票を添付。承認権限マトリックスと実際の運用状況の整合性を確認済み。
2. データ統合コントロール(リスク度:高) - 15拠点からのデータ送信完了チェック - 件数・金額の自動照合 - 例外データの手作業レビュー
調書ノート:例外レポートのサンプルを調書に保管。年間を通じて例外発生率は0.03%で安定推移。
サンプル選定とテスト実施
アクセス管理のテストでは、新規アクセス付与について年間87件から20件を統計的サンプリングで選定した。アクセス権棚卸しは12回の月次レビューを全件確認。退職者アクセス削除は年間23名の退職者を全件確認した。
調書ノート:アクセス管理テストのワークペーパーを別シートに整理。各テスト項目の合格/不合格理由を明記。
データ統合コントロールのテストでは、日次データ照合について営業日数247日から25日をランダムサンプリングした。例外処理は発生した例外74件から15件を選定してフォローアップ確認を行った。
調書ノート:データ照合の自動処理ログとエラーレポートをPDFで保管。例外処理の調査記録と承認者サインを確認済み。
不備の評価と結論
テスト結果として、2件の軽微な不備を識別した。
1. 1名の退職者アクセス削除が退職日から3日遅れ(人事からIT部門への通知遅延が原因) 2. 月次アクセス権棚卸しにおいて、1部門で承認日が期限を1日超過
調書ノート:識別された不備について、根本原因分析と管理者の改善措置を文書化。軽微な不備と判定した理由を明記。
田中ロジスティクス社のITコントロールは、軽微な不備はあるものの、全体として有効に機能していると判断。識別された不備は管理者により速やかに改善措置が講じられ、システム全体のコントロール目標の達成に対する影響は限定的であった。
監査人が確認するドキュメント
システムドキュメント類
システム構成図とデータフロー図は、システム全体のアーキテクチャと主要なデータの流れを理解するための基礎資料である。外部システムとのインターフェイス、データ変換処理、例外処理の流れを詳細に確認する。
コントロール設計書は、各コントロールの目的、実施者、実施頻度、証跡の保管方法を記載した文書。ISAE 3402.64では、コントロールの設計を理解し評価するために必要な文書と定められている。経験上、設計書と実際の運用が一番ズレやすい。ここは入念に突き合わせるべきポイントだ。
運用記録とログ
システムアクセスログでは、特権アクセス、システム管理者アクセス、夜間・休日アクセスを重点的に確認する。異常なアクセスパターンがないか、承認されていないアクセスがないかを分析する。
変更管理記録では、システム変更の申請書、承認記録、テスト結果、本番適用記録を一連の流れとして確認する。緊急変更については、事前承認の省略理由と事後承認の実施状況を確認する。
例外・エラーレポートでは、システムが自動生成する例外レポートの完全性と正確性を確認する。主要な例外については、調査結果と対応措置の記録を詳細に確認する。未解決の例外がある場合は、その影響度と管理状況の評価が求められる。
コンプライアンス関連文書
セキュリティポリシーは、情報セキュリティに関する基本方針と具体的な実施基準を定めた文書である。ポリシーの内容が実際のコントロールに反映されているか、従業員への周知・教育が行われているかを確認する。
業務継続計画(BCP)は、災害や障害時の業務継続に関する計画書。計画の実行可能性、定期的な見直し、訓練の実施状況を確認する。監基報315.A128は、IT環境における業務継続性の評価について述べている。
よくある不備と対処法
アクセス管理の不備
職務分離の不徹底が典型的なパターンとなる。同一人物が申請から承認、実行まで複数の役割を担っている場合がある。小規模組織では完全な職務分離が困難な場合も多い。こうした場合は、代替統制(上位承認者による事後レビュー、定期的なモニタリング等)の整備を確認する。
特権アクセスの管理不備も頻出する。システム管理者アカウントの共有使用、パスワードの定期変更未実施、作業内容の記録不備。品管からの指摘事項として繰り返し挙がる問題であり、CPAAOBの検査でも監査品質に直結する問題として指摘されることが多い。ここは何年やっても完全にはなくならない気がする。
変更管理の不備
テスト不十分による本番障害は避けたい。開発環境でのテストが足りず、本番環境でエラーが発生する事例がある。テスト計画の妥当性、テストケースの網羅性、テスト結果の評価。この3点の確認が基本だ。
緊急変更の事後承認漏れも見落としやすい。システム障害等の緊急時に実施した変更について、事後の承認手続が漏れている場合がある。緊急変更については、実施理由の妥当性、変更内容の妥当性、事後承認の確実な実施を確認する。
データ完全性の不備
インターフェイス処理エラーの見落としは、システム間のデータ連携において、エラーが発生しているにもかかわらず調査・修正が行われていない場合に起こる。エラーレポートの確認体制、調査プロセス、修正措置の実効性を評価する。
残高照合の差異放置も問題になる。月次の残高照合で差異が発生しているにもかかわらず、原因調査や修正措置が講じられていない場合がある。差異の金額的な大きさ、発生頻度、累積影響を考慮して評価する。
実務チェックリスト
このチェックリストは明日の業務で即座に使用できるよう設計した。
1. ITコントロール識別の完全性確認 - GITC(アクセス管理、変更管理、バックアップ等)の漏れはないか - 業務処理コントロール(自動・手作業)の識別は妥当か - 各コントロールのリスク度評価はリスクベースで実施されているか - ISAE 3402.A73の分層アプローチに従っているか
2. テスト計画の妥当性確認 - サンプル数は統計的妥当性を確保しているか(日次20-25、週次15-20、月次8-12) - サンプル選定方法は偏りを排除できているか - テスト対象期間は報告対象期間をカバーしているか - 自動コントロールと手作業コントロールでテスト手法を使い分けているか
3. 証拠収集の十分性確認 - 各コントロールについて設計有効性と運用有効性の両方を確認したか - システム設定、承認記録、実施記録等の証跡を入手したか - 例外事項について根本原因分析と対応措置を確認したか - 第三者による独立検証(ITスペシャリストのレビュー等)を受けたか
4. 不備評価の確認 - 識別された不備の影響度評価は妥当か - 軽微な不備と大きな不備の区分は明確か - 管理者の改善措置には実効性があるか - 不備が他のコントロールに与える影響を評価したか
5. 調書の完全性確認 - テスト手続、サンプル選定理由、実施結果を詳細に記録したか - 結論に至った判断根拠を明確に記載したか - 必要な証拠書類を調書に添付・保管したか - ISAE 3402.68が要求する「十分かつ相当な証拠」の基準を満たしているか