内部監査の現場で「IT全般統制(ITGC)」の評価だけは外部の専門家に任せきり、あるいは毎年ほぼ同じチェックリストをなぞるだけ ── そんな状態になっていないでしょうか。財務報告の信頼性を支える土台でありながら、内部監査部門にITに精通した人材が少ないために、ITGCは”手をつけにくい領域”になりがちです。
本記事は、ITに詳しくない内部監査担当者が、ITGCの全体像と勘所を実務目線でつかめるようにまとめたものです。とりわけ、クラウド・SaaSが当たり前になった現在の環境でどう見るべきかに踏み込んでいきます。
そもそもIT全般統制(ITGC)とは何か
IT全般統制(ITGC: Information Technology General Controls)とは、業務システムが「正しく、継続的に、権限を持った人だけによって」運用されることを担保するための統制の総称です。
会計や財務報告の文脈でなぜこれが重要になるのか。ポイントは、個々の業務処理統制(ITAC:IT Application Controls)が有効に機能する前提として、ITGCが効いている必要があるという関係にあります。たとえば「承認された取引しか登録できない」というシステム上の制御(業務処理統制)が正しく働いていても、その裏でプログラムが誰でも自由に書き換えられたり、管理者権限が野放しになっていたりすれば、統制そのものの信頼性が崩れてしまいます。
つまりITGCは、システムに組み込まれた個別の統制を”下支え”する基盤統制です。ここが崩れていると、その上に乗るすべての自動化された統制の信頼性が揺らぐ ── だからこそ、財務報告に係る内部統制(J-SOX)の評価においてITGCが重視されるわけです。
この関係を図にすると、次のような三層構造になります。最下層のITGC(基盤)が、その上の業務処理統制(ITAC)を下支えし、最終的に財務報告の信頼性を支えています。
ITGCの4つの評価領域
ITGCは、実務上おおむね次の4領域に整理されます。内部監査で「何を見ればよいか分からない」となりがちなので、まずこの枠組みを押さえるのが出発点です。
1. アクセス管理(論理アクセス)
誰がどのシステム・データにアクセスできるかを適切に制限・管理できているか。ID・パスワードの管理、権限付与・変更・剥奪のプロセス、そして特に特権ID(管理者権限)の管理が焦点になります。ITGCの不備として最も頻出するのがこの領域で、退職者のIDが残っている、権限が過剰に付与されている、特権IDの利用が記録・承認されていない、といった問題が典型です。
2. プログラム変更管理
システムのプログラムを変更する際に、承認・テスト・本番反映の各段階が適切に管理され、無許可の変更が本番環境に入らないようになっているか。開発担当者が自分の判断だけで本番システムを書き換えられる状態は、統制上の重大な弱点になります。変更の申請・承認記録、テスト証跡、開発環境と本番環境の分離がチェックの中心です。
3. システム運用管理
日々のシステム運用が安定して行われているか。バッチ処理の正常終了の監視、障害発生時の対応、データのバックアップとリカバリ、ジョブスケジュールの管理などが含まれます。地味な領域ですが、財務データの完全性(欠損・重複がないこと)に直結します。
4. システムの開発・導入
新しいシステムを導入したり、大規模な改修を行ったりする際に、要件定義・テスト・移行・本番稼働の各プロセスが適切に管理されているか。特にデータ移行時の網羅性・正確性の検証は、財務数値の信頼性に直接影響します。ERP導入プロジェクトなどでは、この領域が一時的に大きなリスクとなります。
クラウド/SaaS時代に何が変わったのか
ここからが、多くの既存解説が追いついていない部分です。かつてITGCといえば「自社のサーバールームにある基幹システムをどう管理するか」が中心でした。しかし現在は、会計・人事・SFA・経費精算など、業務の多くがクラウド・SaaSに移行しています。この環境変化は、内部監査の見方を根本から変えます。
責任共有モデル ── 「どこまでが自社の統制範囲か」
クラウドサービスでは、統制の責任がサービス提供事業者(クラウドベンダー)と利用企業(自社)の間で分担されます。これを責任共有モデル(Shared Responsibility Model)と呼びます。
たとえばSaaSの場合、サーバーの物理的セキュリティやインフラの運用はベンダー側の責任範囲であり、通常、自社が直接監査することはできません。一方で、自社アカウント内のユーザー権限設定、アクセス管理、データの取り扱いは利用企業側の責任です。内部監査で最初に整理すべきは「このシステムについて、自社が統制の責任を負う範囲はどこまでか」という線引きです。従来のオンプレ前提のチェックリストをそのまま当てると、ベンダー側の領域を検証しようとして行き詰まったり、逆に自社側の見るべき範囲を見落としたりします。
SOC報告書 ── ベンダー側の統制をどう評価するか
では、自社が直接監査できないベンダー側の統制はどう担保するのか。ここで登場するのがSOC報告書(SOC1/SOC2)です。これは、クラウドベンダーの内部統制が有効に整備・運用されていることを、第三者(監査法人)が検証した報告書です。
内部監査担当者は、主要なSaaSベンダーからSOC報告書を入手し、(1)報告書の対象範囲が自社の利用形態をカバーしているか、(2)報告書に記載された「利用企業側が実施すべき補完的統制(CUEC)」を自社が実際に実施しているか、を確認することになります。SOC報告書は”読めれば強力な武器”ですが、構造や読み方に独特のクセがあるため、ここは別記事で詳しく扱う予定です。
特権IDとアクセス管理の重要性がさらに増す
クラウド環境では、管理コンソールへのアクセス権限を持つ者が、設定変更・データ抽出・ユーザー追加などを画面操作だけで実行できてしまいます。オンプレ時代のように物理的な障壁がないぶん、特権IDの管理とアクセスログの監視の重要性はむしろ高まっています。誰が管理者権限を持ち、その操作が記録・レビューされているか ── クラウド時代のITGCでは、この点が最重要チェックポイントの一つになります。
内部監査担当者が最低限おさえるべき視点
ITに詳しくなくても、次の視点を持って臨めば、ITGCの評価は着実に前に進みます。
第一に、評価対象システムの棚卸から始めること。財務報告に重要な影響を与えるシステムはどれか、それぞれがオンプレかクラウドか、という整理がすべての出発点です。第二に、それぞれのシステムで自社が責任を負う統制範囲を線引きすること。クラウドならベンダー領域はSOC報告書で、自社領域は実地の検証で、と役割を分けます。第三に、4領域のうちアクセス管理(特に特権ID)を最優先で見ること。不備の発生頻度と財務報告への影響度がともに高く、費用対効果が最も高い領域です。
そして何より、ITGCは「ITの専門知識を問う領域」ではなく「統制の考え方をITに適用する領域」だと捉え直すことが、内部監査部門にとっての突破口になります。技術の詳細をすべて理解する必要はありません。”何が担保されていれば信頼できるのか”を問う姿勢こそが本質です。
まとめ
本記事では、ITGCの全体像を4領域で整理し、クラウド/SaaS時代に内部監査の見方がどう変わるかを俯瞰しました。ITGCは、内部監査部門がITに不慣れであっても、正しい枠組みさえ持てば十分に扱える領域です。
今後は、本記事で触れた各論点 ── 特権ID・アクセス管理の具体的な監査手法、SOC報告書の読み方、プログラム変更管理の確認ポイント、クラウドの責任共有モデルの実務対応など ── を一つずつ掘り下げていきます。会計とITの双方に軸足を置く立場から、内部監査の現場で本当に役立つ実務知識をお届けしていきます。
本記事は一般的な実務解説であり、個別の会計・監査上の判断については貴社の状況に応じた検討が必要です。ITGCの評価体制の構築や内部監査支援について、みずぐち公認会計士・税理士事務所にお気軽にご相談ください。