内部統制とIT統制の違いとは？3種類の分類と実務の進め方

「内部統制」と「IT統制」、この2つの言葉の関係を聞かれて、即答できる方は多くありません。「IT統制は内部統制の一部」までは何となくご存じでも、内部統制のどこに位置づくのか、なぜ独立した論点として扱われるのかまでは説明できない、という方をよく見かけます。

結論から言うと、内部統制とは、組織の業務において不正・不法な行為が行われないように業務手続きを定め、それを適切に運用していく活動全体のことです。内部統制は会社全体のルールを指す広い概念で、IT統制はその中でも特にシステムの開発・運用・利用に関わるルールに特化した概念にあたります。金融庁が公開している「財務報告に係る内部統制の評価及び監査の基準」では、内部統制を構成する6つの基本的要素（統制環境・リスクの評価と対応・統制活動・情報と伝達・モニタリング・ITへの対応）が定められており、IT統制はこのうち「ITへの対応」にあたる概念です。

現代のビジネスがITに依存している以上、IT統制抜きに内部統制を完成させることはできません。この記事では、内部統制とIT統制の関係、IT統制の3種類、そして実務でIT統制をどう構築・評価していくかまでを、一つの記事にまとめて整理します。

この記事を読んでわかること

内部統制とIT統制の関係（内部統制6要素の中でのIT統制の位置づけ）
IT統制の3種類（IT全社的統制・IT全般統制・情報処理統制）とそれぞれの役割
IT統制を構築する実務ステップと、評価範囲・評価項目の決め方（RCM）
外部委託・クラウド時代のIT統制とSOCレポートとの関係
J-SOXの中でIT統制がどう扱われるか
IT統制を担当すべき部門と、現場でよくある失敗パターン

内部統制とIT統制の関係：まず位置づけを整理する

内部統制とIT統制は、しばしば同列で語られますが、対等な関係ではありません。内部統制が親の概念で、IT統制はその一部にあたります。

内部統制の目的は、大きく「業務の有効性・効率性」「財務報告の信頼性」「事業活動に関わる法令等の遵守」「資産の保全」の4つに整理されます（金融庁「財務報告に係る内部統制の評価及び監査の基準」）。この目的を達成するための手段として、統制環境・リスクの評価と対応・統制活動・情報と伝達・モニタリング・ITへの対応という6つの基本的要素が定められています。

IT統制は、この6要素のうち「ITへの対応」を具体化したものです。会社の業務がシステム抜きに回らない以上、内部統制の実効性はシステムの信頼性に大きく左右されます。売上・仕入・在庫といった財務数値の多くが会計システムや業務システムを経由して集計される現代の企業では、システムが正しく機能していなければ、他の5要素をどれだけ整えても内部統制全体が崩れてしまいます。IT統制が「内部統制の一部でありながら独立した論点として扱われる」理由は、ここにあります。

IT統制の3種類：IT全社統制・IT全般統制・情報処理統制

IT統制という言葉は、実は1つの概念ではなく3つの概念をまとめた総称です。ここを分けずに理解しようとすると、話がかみ合わなくなってしまいます。

区分	対象の広さ	見ているもの	具体例
IT全社統制	会社全体	ITガバナンスの体制・方針	情報セキュリティポリシーの有無、CISOの設置、IT投資の意思決定プロセス
IT全般統制（ITGC）	個々のシステム	システムが信頼できる状態で運用されているか	変更管理・運用管理・アクセス管理・外部委託管理
情報処理統制（IT業務処理統制／ITAC）	業務アプリの中身	データ処理が正確に行われているか	売上データの取込みロジックが正しいか、入力エラーが検知されるか

3つの関係は「会社全体 → システム単位 → 処理単位」と対象範囲が狭くなっていくイメージで捉えると整理しやすくなります。

3つの中でも、IT全般統制は特別な位置にあります。情報処理統制は「システムの中の計算が正しいか」を見る領域ですが、その計算をしているシステム自体が「誰でも改ざんできる」「テストなしにコードが変わる」「退職者もログインできる」状態では、計算が正しくても意味がありません。IT全般統制は、システムそのものが信頼できる状態で運用されているかを確保する役割を持ちます。3種類の中でIT全般統制が「土台」と呼ばれるのはこのためです。IT全般統制の内訳（変更管理・IT業務管理・アクセス管理・外部委託管理の4領域）は、このシリーズの別記事でさらに詳しく扱っています。

IT統制が重要な理由

IT統制が求められる理由は、大きく3つに整理できます。

財務報告の透明性と信頼性の確保。上場企業・IPO準備企業では、J-SOX（金融商品取引法に基づく内部統制報告制度）によりIT統制を含む内部統制の評価・報告が義務づけられています。IT統制が不備だと、監査人はシステムに依拠したテストができず、手動での全件確認に切り替えざるを得なくなり、監査対応のコストと期間が跳ね上がります。

不正・誤りのリスクを抑える。アクセス権限が野放しになっていれば、退職者や無関係な担当者がデータを改ざんできる状態になります。IT統制はこうした不正や意図しない誤りが起きにくい仕組みを作ります。

業務プロセスの標準化。属人的な運用が、証跡の残るルールベースの運用に置き換わることで、担当者が変わっても業務が回る状態を作れます。IPO審査で問われる「経営者が変わっても会社が今まで通り回る仕組みを作れているか」という観点にも直結します。

資金調達・信用力の評価材料になる。IPOを目指す企業に限らず、M&Aのデューデリジェンスや金融機関からの融資審査でも、内部統制・IT統制がどの程度整っているかが評価対象になる場面があります。「システムがブラックボックスで、誰が何をどう変更しているか説明できない」状態は、それ自体が経営リスクとして受け取られやすいものです。

これら4つは独立した理由ではなく、根っこは1つです。IT統制が整っていない会社は、良くも悪くも「担当者の頭の中にしか業務のロジックがない」状態になりやすい傾向があります。IT統制はその状態を、誰でも検証できる形に置き換えるための仕組みだと捉えると分かりやすいと思います。

IT統制を構築する実務ステップ

IT統制の構築は、いきなり4領域・3種類を個別に整備し始めるものではありません。実務では次の順序で進めます。

STEP1現状把握（システム構成・業務プロセスの棚卸）

→

STEP2評価範囲・評価項目の決定（RCM）

→

STEP3運用ルールの整備・実行

→

STEP4定期的な評価・改善

STEP1：現状把握

どのシステムがどの業務に関わっているか、データがどこから来てどこへ流れているかを洗い出します。この全体像がないまま個別の統制を作り始めると、重要なシステムが評価対象から漏れたり、逆に重要性の低いシステムに過剰な工数をかけてしまったりします。

STEP2：評価範囲・評価項目の決定（RCM）

現状把握ができたら、財務諸表への影響度・利用範囲・カスタマイズの有無といった軸で、評価対象とする範囲を絞り込みます。この整理に使われるのがRCM（リスクコントロールマトリクス）です。RCMは「リスク×統制活動」を対応づける表ですが、ありがちな失敗は、フォーマットさえ埋めれば評価が終わったと思い込んでしまうことです。実際には「何が起きたら財務報告が誤るか」というリスクの識別が先にあり、統制活動はその後に決まる、という順番を守る必要があります。この順番が逆になると、何を防いでいるか分からないRCMができあがってしまいます。

STEP3：運用ルールの整備・実行

評価範囲が決まったら、変更管理・アクセス管理などの運用ルールを文書化し、実際に運用します。統制と業務効率のバランスを欠くと、ルールが形骸化し「作ったが誰も守っていない」状態になりやすいので注意が必要です。

STEP4：定期的な評価・改善

一度作ったルールを運用し続けるだけでなく、システム変更や組織変更に応じて定期的に評価・見直しを行います。この継続性がなければ、統制は「一度作って終わり」の書類仕事になってしまいます。

IT統制の構築、どこから手をつけるべきか迷っていませんか

月次決算・IPO準備・IT統制の実務知見を、月1回メールでお届けします

無料でメルマガを受け取る

IT統制の評価項目：監査で何を見られるか

IT統制の評価では、IT全社的統制・IT全般統制・情報処理統制それぞれで見られる観点が異なります。実務でよく確認されるのは、次のような項目です。

IT全社統制の評価項目

IT戦略がそもそも適切に設定されているか、情報セキュリティポリシーが文書化され、社内に周知されているか。CISOや情報システム責任者など、ITガバナンスの責任の所在が明確になっているか。新しいシステムを導入する際の意思決定プロセス（誰が承認し、どんな基準で選定するか）が定められているかなどを評価します。これらは「仕組みをそもそも作れる体制か」「大前提のルールがあるか」を見る項目であり、個々のシステムの中身までは踏み込みません。

IT全般統制の評価項目

変更管理：変更の要件が記録されているか、開発・テスト・本番の環境が分離されているか、本番反映は承認を経ているか
運用管理：バッチ処理のスケジュールと実行結果が記録されているか、バックアップが計画どおり実行され復旧可能な状態か
アクセス管理：権限の新規付与・変更が承認されているか、退職・異動時のアカウント削除フローがあるか、定期的なアクセスレビュー（アカウント棚卸）が行われているか、特権IDが最小人数に絞られているか
外部委託管理：重要なベンダーのSOCレポートを取得・確認しているか、委託先選定時のリスク評価プロセスがあるか

この4領域のうち、監査で最も指摘が出やすいのはアクセス管理です。退職者アカウントの放置や、特権IDの棚卸未実施は、規模の大きい会社でも珍しくありません。

情報処理統制の評価項目

入力管理（金額や数量の入力時に、範囲外の値をエラーとして検知する仕組みがあるか）、マスタデータの維持管理（取引先マスタ・勘定科目マスタの変更が承認を経ているか）、処理結果の照合・承認（バッチ処理の結果を人が確認するタイミングがあるか）。情報処理統制はIT全般統制と違い、業務プロセスごとに個別の評価が必要になる点が実務上の負荷になりやすい領域です。

評価対象のシステムが多いほど、この確認作業は膨らんでいきます。だからこそSTEP2の評価範囲の絞り込みが、実務上の分かれ目になります。「とりあえず全部評価する」という発想は、担当者の工数を圧迫するだけでなく、本当に重要なリスクへの目配りを薄めてしまいます。

外部委託・クラウド時代のIT統制とSOCレポートの関係

クラウド・SaaSの利用が当たり前になった今、外部委託管理は最も対応が難しい領域になっています。自社サーバーであれば自社で統制を確認できますが、AWSやSaaSベンダーの内部で何が行われているかを、利用者側が直接確認することはできません。ここで登場するのがSOCレポートです。

SOCとは「System and Organization Controls」の略で、米国公認会計士協会（AICPA）が定めたフレームワークです。委託先のサービスに関する内部統制の整備・運用状況を、独立した第三者（会計事務所）が評価・報告したものにあたります。実務でよく出てくるのは

SOC1（財務報告への影響を評価）
SOC2（セキュリティ・可用性等を評価）

の2種類で、それぞれに設計評価のみのTypeⅠと、一定期間の運用評価まで含むTypeⅡがあります。監査の現場では、TypeⅡが求められることが多いです。

SOCレポートを受け取ったときに見落とされがちなのが、UEC（利用者エンティティコントロール）です。UECは「利用者側（自社）が実施しなければならない統制」の一覧で、委託先のSOCレポートがあっても、自社側でUECの要件を満たしていなければ統制上の穴が生じてしまいます。この「取り寄せて満足してしまい、UECを読んでいない」状態は、外部委託管理における不備として、現場で最も頻出するパターンの一つです。

もう一つ見落とされやすいのがCSOC（補完的なサブサービス組織の統制）です。委託先がさらに別の外部委託先（サブサービス）を使っている場合、そのサブサービス側の統制をどう前提にしているかがSOCレポート内に記載されます。
たとえばAWS上で稼働するSaaSであれば、「AWSのデータセンター管理の統制はAWS側のSOCレポートに依存する」という形で記載されることがあり、この場合はAWS側のSOCレポートも別途確認する必要が生じます。委託先1社のSOCレポートだけを見て安心してしまうと、その先に連なるサブサービスの統制が抜け落ちてしまいます。

J-SOXにおけるIT統制の位置づけ

上場企業・IPO準備企業では、J-SOX対応の内部統制評価ので行われます。IT統制の位置づけは、以下のようになっております。

実務でありがちなのは、売上・購買といった業務プロセス統制の評価を優先し、IT統制は「システム部門に任せておけばいい」と後回しにされることです。
しかしIT全般統制に不備があると、業務プロセス統制側の評価も「システムに依拠した効率的なテスト」から「手動での全件確認」に切り替わらざるを得なくなります。この依存関係が監査スケジュールの後半で発覚すると、是正の時間が確保できなくなってしまいます。IT統制はJ-SOX対応の初期段階で着手すべき領域、というのが実務上の結論です。

IT統制を担当すべき部門・体制

IT統制は、情報システム部門だけの仕事でも、内部監査部門だけの仕事でもありません。

情報システム部門は、システムの構成・運用ルールを実際に整備・運用する立場にあります。一方、内部監査部門（または経理・内部統制担当者）は、財務報告の信頼性という観点からその運用が十分かを評価する立場にあります。この2つの視点が揃って初めて、IT統制は「作っただけ」ではなく機能する統制になります。

実務では、監査チームに会計士がいてもAWS・GitHub・JIRAなどのツールに触れたことがない場合が多く、逆にエンジニア側は「なぜソースコードを見ないのか」「セキュリティは問題ないのに何が足りないのか」と疑問を持ちやすいものです。これはどちらかの認識が間違っているのではなく、IT統制が財務報告の信頼性を担保するためのものだという前提がすれ違っているだけ、というケースが多いというのが実感です。会計とITの双方のリテラシーを持つ人間が間に入ることが、実務上は現実的な解になります。

会社の規模・成長フェーズによって体制は変わる

小規模な会社では、情報システム部門も内部監査部門も専任者がいないことが珍しくありません。この段階では「誰が担当するか」よりも「経営者自身がシステムの構成を把握しているか」のほうが実質的に重要になります。担当者が1人しかいなければ、その人が異動・退職した瞬間に統制が丸ごと失われるリスクがあるためです。

会社の規模が大きくなり、IPO準備やJ-SOX対応が視野に入る段階になって初めて、情報システム部門・内部監査部門という役割分担が意味を持つようになります。逆に言えば、小規模な段階から上場企業と同じ密度の統制を作り込もうとすると、運用が回らずに形骸化しやすいものです。会社の成長フェーズに見合った作り込みの度合いを見極めることも、IT統制を機能させるうえで欠かせない判断になります。

現場でよくある失敗パターン

私がこれまで見てきた中で、IT統制の構築でよく起きる失敗は、3つのパターンに集約されます。

失敗パターン1：評価対象を機械的に広げすぎる

現状把握を飛ばしていきなり全システムを同じ深さで評価しようとし、工数が膨らんで頓挫してしまうケースです。
逆に「去年と同じ項目でいいや」で済ませて、システム構成が変わった箇所を見落とすケースも、同じ根っこの問題です。評価範囲を決める作業を「一度決めたら固定するもの」ではなく、事業やシステム構成の変化に合わせて見直すものとして扱う必要があります。

失敗パターン2：ルールを作って終わりにする

運用ルールを文書化した時点で満足し、実際に守られているかのモニタリングを怠ってしまうケースです。
退職者アカウントの放置や、特権IDの棚卸未実施は、この失敗パターンの典型です。「ウチはアジャイルなので」という言い訳のもとで仕様書も議事録もなく、デプロイのタイミングも管理されていない、というケースも同じ構造で起きます。アジャイル開発そのものが悪いわけではありません。証跡が残らない開発プロセスが、免罪符のように扱われてしまうことが問題なのです。

失敗パターン3：外部委託先の統制を確認したつもりになる

SOCレポートを取り寄せただけで「確認した」と処理し、UECの要件を自社で満たしているかまで踏み込まないケースです。SOCレポートには有効期限があり、TypeⅡであれば評価期間が明記されています。古いレポートを持っていても、最新の統制状況の証拠にはなりません。毎年更新されたレポートを取り寄せる運用を仕組み化しておく必要があります。

いずれの失敗も、IT統制を「一度作れば終わりの書類仕事」として扱ってしまうことが根本原因になっています。不備が見つかったときに求められる是正は、ルールの修正だけで済むこともあれば、組織構造を含めた見直しが必要になり時間がかかることもあります。だからこそ、情報システム部門とガバナンス担当（内部監査・経理）が日常的に連携できる関係を作っておくことが、結果的に一番の近道になります。

よくある質問（FAQ）

Q. 内部統制とIT統制はどちらが広い概念ですか？
A. 内部統制のほうが広い概念です。内部統制を構成する6つの基本的要素（統制環境・リスクの評価と対応・統制活動・情報と伝達・モニタリング・ITへの対応）のうち、「ITへの対応」を具体化したものがIT統制にあたります。

Q. IT統制とIT全般統制は同じ意味ですか？
A. 同じではありません。IT統制はIT全社的統制・IT全般統制・情報処理統制の3種類をまとめた総称で、IT全般統制はそのうちの1つです。

Q. IT統制は誰が担当すべきですか？
A. 情報システム部門（実際の運用）と内部監査部門・経理部門（財務報告の信頼性の観点での評価）が連携して担当するのが望ましい体制です。

Q. クラウドサービスを使っている場合、IT統制はどう確認しますか？
A. 委託先が発行するSOCレポート（SOC1／SOC2）を取得し、監査意見・UEC（自社が実施すべき統制）の記載を確認します。取り寄せるだけで終わらせず、UECの要件を自社で満たしているかまで確認する必要があります。

Q. IT統制の評価はいつから始めるべきですか？
A. J-SOX対応やIPO準備を進める企業では、業務プロセス統制の評価より前、初期段階での着手が望まれます。IT全般統制に不備があると、業務プロセス統制側の評価にも影響するためです。

内部統制・IT統制の構築や評価をご検討の方へ

会計とITの橋渡し役として、内部統制・IT統制の整備を第三者目線でご支援します。J-SOX対応・SOCレポート取得もあわせてサポート可能です。

サービス詳細を見る
 無料相談・お問い合わせ

まとめ

内部統制は会社全体のルール、IT統制はその中の「ITへの対応」を具体化したもの。内部統制の6基本的要素の1つがIT統制にあたる
IT統制は「IT全社的統制・IT全般統制・情報処理統制」の3種類で構成され、対象範囲が「会社全体→システム単位→処理単位」と狭くなっていく
構築は「現状把握→評価範囲・評価項目の決定（RCM）→運用ルールの整備→定期評価」の順で進める
外部委託先の統制はSOCレポートで確認し、UEC（自社が実施すべき統制）の見落としに注意する
J-SOX対応では、IT統制（特にIT全般統制）は業務プロセス統制の評価効率を左右するため、初期段階での着手が望ましい
IT統制は情報システム部門と内部監査部門・経理部門が連携して担当する

内部統制・IT統制の構築や評価について相談したい場合は、IT統制構築支援からどうぞ。J-SOX対応・SOCレポート取得もあわせてサポートしています。

参考資料

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