ITGCを任されたら最初に読む：IT全般統制の全体像と4カテゴリ

「IT統制」という言葉はよく耳にする。しかし「IT全般統制」と「情報処理統制」の違いを聞かれると、答えられない人が多い。IT統制の評価を任されたとき、何から手をつければいいかわからない。そういう状況に、現場でよく出会う。

IT統制には3つの種類がある。まずここを整理しないと、個別の話をいくら読んでも全体像がつかめない。IT統制の評価を始める前に、この記事で全体像を押さえてほしい。

IT統制の3種類：まず全体像を整理する

財務報告に関わるIT統制は、大きく3種類に分類される。

この中で、ITに係る内部統制は、① IT全社的統制　② IT全般統制（ITGC）③ 情報処理統制　の３つになる。

ここからは順番に解説していこう。

① IT全社的統制

「ITに関する会社全体の方針・体制」だ。個々のシステムを見る前に、そもそも会社がITをどう管理しているかを評価する。

  • ITガバナンスの体制はあるか（CISOや情報システム責任者がいるか）
  • 情報セキュリティポリシーは文書化されているか
  • IT投資の意思決定プロセスはあるか

実務的には「全社的な内部統制」の評価を行うタイミングで同時に検証することが多いため、IT統制特有の調査はそこまで深く行わないことが多い。

② IT全般統制（ITGC）

IT全般統制とは、「IT環境の継続的かつ適切な運用を支援する企業のITプロセスに係る内部統制」である（監基報315・第11項(2)）。　IT全般統制は、後述する4つのカテゴリに分類される。

  1. 開発・変更・保守管理（変更管理）
  2. 運用管理
  3. アクセス管理
  4. 外部委託管理

③ 情報処理統制

情報処理統制とは、「情報のインテグリティ（すなわち、取引及びその他の情報（データ）の網羅性、正確性、正当性）のリスクに直接対応する内部統制」である（監基報315・第11項(9)）。

たとえば「売上データが会計システムに漏れなく・正確に・正当な権限で連携されているか」を確認する。ITアプリケーションの情報処理、または手作業による情報処理に関連した統制が該当する。

なぜIT全般統制が「土台」なのか

IT統制の中で、IT全般統制は土台にあたる。

情報処理統制は「会計システムの中の計算が正しい」ことを確認する。しかしその会計システム自体が、「誰でも改ざんできる」「テストなしにコードが変わる」「退職者もログインできる」状態では、中の計算が正しくても意味がない。

IT全般統制は「システム自体が信頼できる状態で動いているか」を確保する。IT全般統制が有効であることが確認できてはじめて、情報処理統制の評価が効率的に行える。

逆にIT全般統制に問題があると、監査人はシステムを信頼できないため、手動でのテスト件数を大幅に増やす対応をとらざるを得なくなる。システムが信頼できないということは、自動化した確認（システムが正しく動いているという前提に依拠したテスト）が使えないということだ。結果として、1件ずつ手で拾って確認するしかなくなる。会社にとっても監査対応のコストが跳ね上がる。

IT全般統制の4カテゴリ

IT全般統制のカテゴリは、J-SOX実務では4つに整理することが多い。監基報315では変更管理・IT業務管理・アクセス管理の3プロセスが主軸で、外部委託管理は別途扱われる。実務では4つで覚えておくと整理しやすい。

カテゴリ1：変更管理

システムのプログラムや設定への変更が、適切なプロセスを経て行われているかを見る。

監査で確認することは以下の通りである。

  • 変更の要件が記録されているか
  • 開発・テスト・本番の環境が分離されているか
  • 本番への反映は承認を経て行われているか
  • コードレビューがなされているか

また、変更管理に関連する主なツールとして、 GitHub（PRと承認フロー）、Jira/Backlog（変更要件の記録）などがある。

カテゴリ2：IT業務管理

ジョブ・スケジューリング、バックアップと復旧、侵入の検出など、日々のIT業務が正しく機能しているかを見る。

監査で確認することは以下のとおりである。

  • ジョブ・スケジューリング：バッチ処理のスケジュールと実行結果の記録
  • ジョブの監視：エラー発生時の通知・対応手順
  • バックアップと復旧：財務報告データのバックアップが計画どおり実行され、復旧可能な状態か

また、運用管理に関連する主なツールとして、AWS CloudWatch（監視・アラート）、AWS RDS（スナップショット）、digdag/Airflow（バッチ管理）などがある。

カテゴリ3：アクセス管理

アクセス管理では、誰がどのシステムにどんな権限でアクセスできるかが適切に管理されているかを見る。

監査で確認することは以下のとおりである。

  • 権限付与プロセス：権限の新規付与・変更プロセスは承認されているか
  • アカウントの変更や削除：退職・異動時のアカウント削除・変更フローはあるか
  • 利用者アクセスレビュー：定期的に付与している権限を再確認しているか
  • 特権アクセス：管理者権限は最小人数に絞られているか

カテゴリ4：外部委託管理

外部委託のエンジニアや外部サービスの利用可能性を検証している。

監査で確認することは以下の通りである。

  • 重要なベンダーのSOCレポートを取得・確認しているか
  • 委託先選定時のリスク評価プロセスはあるか
  • 定期的なモニタリング（年次評価等）を実施しているか

複数の基準と用語の対応関係

IT統制を学ぶと、基準によって用語が違うことに気づく。監査基準委員会報告書315（現行）とJ-SOXでは呼び方が異なるが、実態は同じものを指している。以下の対応表で整理しておくと混乱が減る。

項目新315（現行）J-SOX
変更管理プログラムや他のIT環境への変更を管理するためのプロセスシステムの開発・保守
運用管理IT業務を管理するプロセスシステムの運用・管理
アクセス管理アクセス管理のプロセス内外からのアクセス管理
外部委託管理—外部委託に関する契約の管理

呼び方は基準によって違うが、見ている対象は基本的に同じという理解で良いだろう。

実務でどう使うか：評価の順番と不備が出たときの対処

IT全般統制の評価は、上記4カテゴリを順番に片付けるものではなく、まずは「システム構成と業務プロセスの理解」から始める。どのシステムがどの業務に関わっているか。データはどこから来てどこへ流れるか、開発体制や運用体制をどのように構築しているか、これらのリスクがどこにあるかをまずは検討する。この全体像がないまま個別のカテゴリを見ても、何が重要でどこに不備があるかを正しく判断できない。

4カテゴリはその全体像を踏まえて並行して評価する。この作業には業務とITの双方への理解が必須だ。どちらか一方しかわからない評価者では、現場の実態を正しく把握することが難しいだろう。

現場でよく見る不備のパターン（著者の実体験より）

最も頻繁に出る不備はアクセス管理だ。例えば、退職者のアカウントが残ったままログインできる状況にある、全員が管理者権限を持っていて勝手に契約内容を変更できるという状態は珍しくない。また、アカウント棚卸についても定期的に行っていないばかりか、どのシステムを契約しているのかすら管理できていないことも多い。

また、変更管理では、「ウチアジャイルなんで！」という言い訳をして、仕様書も議事録もなく、デプロイのタイミングも管理されていない。ノリで開発が進んでいた、という表現がそのまま当てはまるケースが散見される。

もちろんアジャイルを否定するわけではないが、それが「ドキュメントや証跡を残さない。手順を決めない」という免罪符にしてはならない。

不備が出たときには修正が求められることも多いが、場合によっては組織構造を含めて改造することになるため、時間がかかることも多くなる。そのことから、社内でも開発部門とガバナンス担当が連携を行うことが望ましい。

よくある会計担当者とエンジニアのすれ違い

IT全般統制の評価現場では、会計担当者とエンジニアの間で頻繁にすれ違いが起きる。

会計担当者側の困りごと

監査チームに会計士がいても、AWS・GitHub・JIRAなどのツールに触れたことがない場合は多い。バッチ処理の意味がわからない、アジャイル開発が何かわからない、という状態でITGCを評価することになる。

さらに「何の基準に従って評価しているのか」自体が整理できていないケースもある。監査基準報告書なのか、J-SOXの実施基準なのか。基準が複数あることは知っていても、自分が今どれを使って何を評価しているかがわかっていない場合もある。

エンジニア側の困りごと

エンジニアにとっては、そもそもIT統制が何かわかっていないから、何を求められているのかわからないことが多い。

そのため、「なぜソースコードを見ないのか」「セキュリティは問題ないのに何が足りないのか」という疑問が出やすい。

IT統制が財務報告の信頼性を担保するためのものだという前提がないと、監査人の質問の意図が理解できない。

「アジャイルで開発しているのに仕様書を求められる」「AWSの自動バックアップがあるのにそれでは不十分と言われる」という摩擦も現場では頻出する。これはエンジニアの認識が間違っているのではなく、IT統制が何を確認しているかの前提がすれ違っているだけのことが多い。

そのことから、IT統制を適切に整備・運用させるためには、会計とITの双方のリテラシーを持つ人間が間に入ることが現実的な解になる。

まとめ

  • IT統制には「IT全社的統制・IT全般統制・情報処理統制」の3種類がある
  • IT全般統制（ITGC）は「システム自体が信頼できる状態で運用されているか」を担保する土台
  • 4カテゴリは「変更管理・IT業務管理・アクセス管理・外部委託管理」（監基報315では変更管理・IT業務管理・アクセス管理の3プロセスが主軸）
  • J-SOX・新315など基準によって呼び方は違うが、見ている対象は同じ
  • IT全般統制が不備だと、監査コストが跳ね上がる

IT全般統制の構築・評価について相談したい場合は、お問い合わせからどうぞ。

関連記事

参考資料

  • 「財務報告に係る内部統制の評価及び監査の基準」（金融庁・企業会計審議会）
  • 「財務報告に係る内部統制の評価及び監査に関する実施基準」（金融庁・企業会計審議会）
  • 「監査基準委員会報告書315（改訂）——重要な虚偽表示リスクの識別と評価」（日本公認会計士協会）
  • COBIT 2019 Framework（ISACA）

おすすめ記事

一覧へ