期末まで残り2か月。経理部から内部監査室に回ってきたのは、会計システムを数年前にクラウド型へ移行したという一文と、ベンダーから取り寄せた英文のPDFでした。表紙には「SOC 1 Type 2 Report」とあり、ページ数は100を超えています。監査法人からは「この報告書をどう評価したか、記録を見せてください」と依頼が来ています。
オンプレミスの時代なら、サーバー室の入館記録を確認し、情報システム部の担当者にプログラム変更の申請書を見せてもらえば評価の骨格はできました。ところがクラウドでは、サーバーの場所も、パッチを当てる担当者も、自社からは見えません。見えないものをどう評価するのか。その答えの中心にあるのがSOC報告書です。
本記事では、架空のモデルケースを交えながら、ITGC（IT全般統制）の基本から、クラウド・SaaS時代に評価範囲をどう切り分けるか、SOC報告書のどこを読めば「評価した」と言えるのかまでを順に解説します。
この記事の要点
- ITGCは、自動化された業務処理統制が「毎回同じように正しく動く」ことを支える土台の統制で、実施基準は開発・保守、運用・管理、アクセス管理などの安全性確保、外部委託契約の管理の4つを例示しています
- クラウドやSaaSを使っても評価責任は委託者（自社）に残ります。受託会社の統制はSOC報告書で、自社側の統制（CUEC）は自社でテストするのが基本です
- SOC報告書は「意見」「対象期間」「範囲」「例外事項」「CUEC」「再委託先の扱い」の6点を読めば、評価の骨格が固まります
- 対象期間と自社の期末日のずれはブリッジレターと補完手続で埋めます。報告書を入手して保管するだけでは評価したことになりません
ITGC（IT全般統制）とは何か、なぜ生まれたのか
定義：業務処理統制が働く「環境」を守る統制
ITGC（IT General Controls、IT全般統制）とは、金融庁「財務報告に係る内部統制の評価及び監査に関する実施基準」（以下、実施基準）の言葉を借りれば、「業務処理統制が有効に機能する環境を保証するための統制活動」であり、通常は複数の業務処理統制に関係する方針と手続を指します。実施基準は具体例として、次の4項目を挙げています。
- システムの開発、保守に係る管理
- システムの運用・管理
- 内外からのアクセス管理などシステムの安全性の確保
- 外部委託に関する契約の管理
一方、ITAC（IT業務処理統制）は、業務を管理するシステムの中で「承認された業務が全て正確に処理、記録されること」を確保するために業務プロセスに組み込まれた統制です。入力チェック、自動計算、マスタ・データの維持管理などがこれにあたります。両者の違いと自動統制の評価手順はITACとITGCの違い｜自動統制の評価手順で詳しく扱っています。
なぜ「全般」統制が必要なのか
ITGCが独立した評価対象になっている理由は、プログラムの性質にあります。実施基準は、ITを利用した情報システムは「一旦適切な内部統制（業務処理統制）を組み込めば、意図的に手を加えない限り継続して機能する性質を有している」と説明しています。裏を返せば、誰かが手を加えた瞬間に、昨日まで正しかった自動計算が今日から誤るかもしれません。
そこで、「誰が、どんな手続でプログラムやデータに手を加えられるか」を統制するのがITGCです。ITGCが有効であれば、自動化された統制は一度確かめるだけで期間中も同じように動いていたと推定できます。ITGCが崩れていれば、その推定が成り立たず、個々の取引を大量に確かめ直す必要が出てきます。ITGCは「自動統制の効きめを期間全体に延ばす保証」だと捉えると、評価の意味がつかみやすくなります。
J-SOXでの位置づけと2023年改訂
日本の内部統制報告制度（J-SOX）は、金融商品取引法に基づき2008年4月1日以後開始する事業年度から適用されました。制度の土台である「財務報告に係る内部統制の評価及び監査の基準」は、内部統制の基本的要素の一つに「ITへの対応」を置いています。これは米国のCOSOフレームワークにはない、日本独自の整理です。
2023年4月に企業会計審議会が公表した基準・実施基準の改訂（2024年4月1日以後開始する事業年度から適用）では、ITの委託業務に係る統制の重要性が増していること、クラウドやリモートアクセス等の活用に伴うサイバーリスクの高まりを踏まえたセキュリティ確保の重要性が明記されました。また、ITGCの運用評価を一定の複数会計期間に一度とする取扱いについて、「特定の年数を機械的に適用すべきものではない」ことが明確化されています。改訂の全体像はJ-SOX改訂のポイントをご覧ください。
なお、実施基準は同時に、ITGCが有効と評価されても「それだけでＩＴに係る業務処理統制も有効に機能しているという結論に至らない」と注意を促しています。土台が頑丈でも、その上の建物が正しく設計されているかは別に確かめる、という関係です。
ITGCの4領域と主な統制・テスト手続
実務では、実施基準の4項目を「アクセス管理」「変更管理（開発・保守）」「運用管理」「外部委託管理」と読み替えて評価することが多く見られます。監査法人によっては、開発と変更を分けたり、外部委託管理を各領域に分散させたりする整理もあります。自社の区分は監査人と事前にすり合わせておくのが確実です。
領域別の主な統制とテスト方法
次の表は、各領域で財務報告への影響が大きい代表的な統制と、内部監査部門が行う一般的なテスト手続をまとめたものです。
| 領域 | 代表的な統制 | 主なテスト手続 | 典型的な証跡 |
|---|---|---|---|
| アクセス管理 | ID付与・削除の申請承認、退職者の速やかな削除、特権IDの限定、定期棚卸 | 退職者リストとアカウント一覧の突合、付与申請のサンプル検証、棚卸記録の閲覧 | 申請書、ID一覧、人事異動データ、棚卸結果 |
| 変更管理 | 変更の申請・承認、テスト、本番移行の職務分離、緊急変更の事後承認 | 変更一覧（完全性を確認したもの）からサンプル抽出し、承認とテストの記録を確認 | 変更チケット、テスト結果、移行ログ |
| 運用管理 | バッチ処理の監視、障害対応、バックアップとリストア確認 | ジョブ異常の記録と対応の閲覧、リストアテスト記録の確認 | ジョブ監視ログ、障害管理票 |
| 外部委託管理 | 委託契約の管理、SOC報告書の入手と評価、委託先のモニタリング | 契約書・SLAの閲覧、SOC報告書評価調書のレビュー | 契約書、SOC報告書、評価記録 |
アクセス管理の具体的な監査手順はアクセス管理の監査手順｜特権ID・棚卸・退職者アカウントで詳しく解説しています。
「評価範囲」はシステム単位ではなくIT基盤単位で考える
実施基準は、ITGCは通常「業務を管理するシステムを支援するＩＴ基盤（ハードウェア、ソフトウェア、ネットワーク等）を単位として構築する」と述べています。例えば販売・購買・在庫の3システムが同じ基盤上で同じ部門に運用されていれば、ITGCの評価は1セットで足りる可能性があります。逆に、販売はクラウドERP、購買はオンプレミス、在庫はSaaSという構成なら、基盤ごとに3セットの評価が必要になります。
ここで見落とされやすいのが、アプリケーションの下にある層です。会計システムそのものだけでなく、データベース、OS、そして条件によってはネットワークや認証基盤（シングルサインオン）までが評価範囲に入ります。どの層まで評価するかは「その層に手を加えると、財務データや自動統制の結果を変えられるか」で判断します。
評価範囲の記入例
架空のモデルケースとして、年商300億円規模の製造業A社（クラウドERPと経費精算SaaSを利用）の評価範囲整理表を示します。
| システム | 形態 | 関連する主な勘定 | 評価する層 | 受託会社の統制の評価方法 | 自社で評価する統制 |
|---|---|---|---|---|---|
| クラウドERP（会計・販売） | SaaS | 売上、売掛金、仕入、買掛金 | アプリ（自社設定部分）、認証 | SOC1 Type2（期間：前年10月〜当年9月） | ID管理、アドオン変更管理、CUEC |
| 経費精算SaaS | SaaS | 販管費、未払金 | アプリ（ワークフロー設定） | SOC1 Type2 は未提供、SOC2 Type2で代替検討 | 承認ルートの設定変更管理、ID管理 |
| 給与計算 | 外部委託（BPO） | 人件費、未払費用 | 業務委託 | SOC1 Type2 | 支給データの検算（サンプリング） |
| 連結会計パッケージ | オンプレミス | 連結財務諸表全般 | アプリ、DB、OS | （自社運用） | 4領域すべて |
表の右端の列が空欄にならないことが大切です。SaaSであっても、ユーザーIDの付与、権限ロールの設定、ワークフローの承認ルートなどは自社が管理しており、その部分のITGCは自社で評価する必要があります。
クラウド・SaaS時代に評価の何が変わったのか
責任は委託しても消えない
実施基準は委託業務について、「委託者が責任を有しており、委託業務に係る内部統制についても評価の範囲に含まれる」と定めています。情報システムの開発・運用・保守を外部に委託する場合も同じです。クラウドへ移行したからといって、サーバーやアプリケーションの統制が評価対象から外れるわけではありません。
一方で、自社がクラウド事業者のデータセンターに立ち入ってテストすることは現実的ではありません。そこで実施基準は、委託業務の評価方法として、a.サンプリングによる検証（委託業務の結果を自社で検算する）と、b.受託会社の評価結果の利用（受託会社から報告書等を入手して評価の代替手段とする）を示しています。後者の「報告書等」の代表がSOC報告書です。
「責任共有モデル」と内部統制の境界線
クラウド事業者は一般に「責任共有モデル」を示し、物理設備やハイパーバイザーは事業者、OS以上やデータ、ID管理は利用者、といった境界を説明しています。IaaS、PaaS、SaaSの順に事業者側の範囲が広がり、SaaSでは利用者の責任はID・権限・設定・データ入力などに絞られていきます。
内部監査で重要なのは、この境界線を内部統制の言葉に翻訳することです。事業者側の範囲はSOC報告書で評価し、利用者側の範囲は自社のITGCとして評価します。そして境界線の上には、SOC報告書が「利用者側でこれを実施していることを前提にしています」と明記する統制、すなわちCUEC（Complementary User Entity Controls、補完的な利用者側の統制）が並びます。
評価の頻度にも「IT環境の変化」を織り込む
先に触れた2023年改訂の実施基準は、ITGCの運用状況の評価について、前年度の評価結果が有効で整備状況に重要な変更がない項目は、その旨を記録することで前年度の結果を継続利用でき、一定の複数会計期間内に一度の頻度で実施されることがある、としています。ただしその判断は「ＩＴ環境の変化を踏まえて慎重に」行い、必要に応じて監査人と協議すべきとされています。
クラウドやSaaSは事業者側で頻繁にバージョンアップが行われ、自社が何も変えていなくても環境が変わります。「自社は何も変更していないから前年の結果を使える」とは言い切れないのが、クラウド時代の難しさです。事業者のリリースノートを誰が確認し、財務報告への影響をどう判断したかを記録しておくことが、継続利用の前提になります。
SOC報告書の種類と構成を理解する
SOC1・SOC2・SOC3の違い
SOC（System and Organization Controls）報告書は、受託会社の内部統制について、独立した監査人（公認会計士等）が保証を与える報告書の総称です。米国ではAICPA（米国公認会計士協会）、国際的にはIAASBの国際保証業務基準ISAE 3402、日本では日本公認会計士協会の保証業務実務指針3402「受託業務に係る内部統制の保証報告書に関する実務指針」などが根拠になります。
| 種類 | 対象とする統制 | 主な基準 | 想定読者 | J-SOXでの使いどころ |
|---|---|---|---|---|
| SOC1 | 利用者の財務報告に関連する受託会社の統制 | AICPA SSAE 18、ISAE 3402、JICPA保証業務実務指針3402 | 利用会社とその監査人 | 委託業務の評価の中心的な証拠 |
| SOC2 | セキュリティ、可用性、処理のインテグリティ、機密保持、プライバシー（Trustサービス規準） | AICPAのTrustサービス規準、JICPA保証業務実務指針3850 | 利用会社、監督当局など詳細を知る必要がある関係者 | ITGCに対応する部分を補完的に利用 |
| SOC3 | SOC2と同じ規準 | 同上 | 一般（公開用） | 詳細な統制とテスト結果がないため、単独では評価証拠として不十分 |
財務報告のための評価で第一に求めるべきはSOC1です。SOC2は情報セキュリティの観点で作られているため、アクセス管理や変更管理など重なる部分はありますが、財務データの処理の正確性（例えば自動計算や帳票出力）をカバーしていないことがあります。SOC2で代替する場合は、自社のITGCと対応づける作業が別途必要です。
Type1とType2の違い
Type1は「ある時点」における統制の記述と整備状況（デザイン）の適切性について意見を述べるものです。Type2はそれに加え、「一定期間」にわたり統制が有効に運用されていたかについて意見を述べ、監査人が実施したテストの内容と結果が記載されます。J-SOXでは期末日時点の有効性に加え、それを支える運用状況の評価が必要になるため、原則としてType2が求められます。Type1しか入手できない場合は、運用状況を自社の補完手続（委託業務の結果の検算など）で確かめる必要があります。
報告書の一般的な構成
報告書の章立ては発行者により異なりますが、一般に次のような構成です。
- 受託会社監査人の意見（保証報告書）
- 受託会社経営者の確認書（アサーション）
- システムの記述（業務内容、統制目的、統制、CUEC、再委託先）
- 統制目的・統制・監査人のテスト内容とその結果
- 受託会社が提供するその他の情報（監査人の意見の対象外）
最初に1章で意見の種類を確認し、次に3章で範囲とCUECを、4章で例外事項を読むのが効率的な順番です。5章は保証の対象外なので、そこに書かれた改善計画などは評価の証拠としては扱いません。
SOC報告書の読み方：6つのチェックポイント
チェックポイントと確認内容
SOC報告書を入手したら、次の6点を確認し、結果を評価調書に残します。
| # | 観点 | 確認すること | 問題がある場合の対応 |
|---|---|---|---|
| 1 | 意見 | 無限定適正意見か、限定付意見・否定的意見か | 限定の理由となった統制目的が自社の財務報告に関係するか検討し、代替手続を計画 |
| 2 | 対象期間 | 期間が自社の会計期間をどれだけカバーしているか | 期末日までのギャップはブリッジレターと補完手続で対応 |
| 3 | 範囲 | 自社が利用するサービス、拠点、システムが含まれているか | 含まれていない場合は別の証拠を入手 |
| 4 | 例外事項 | テストで逸脱が検出された統制と、その内容・件数・受託会社の対応 | 自社への影響を評価し、必要に応じ追加手続 |
| 5 | CUEC | 利用者側で実施すべき統制の一覧 | 自社の統制にマッピングし、自社でテスト |
| 6 | 再委託先 | 再委託先（データセンター等）の統制が除外方式（カーブアウト）か包含方式（インクルーシブ）か | カーブアウトの場合は再委託先のSOC報告書も入手・評価 |
実施基準は、受託会社の報告書等を評価の代替手段とする際、「当該報告書等が十分な証拠を提供しているかどうかを検討しなければならない」としています。上の6点は、この「十分かどうか」を検討した証跡そのものです。
例外事項の読み方
4章に「例外事項なし（No exceptions noted）」と書かれていれば安心、とは限りません。まず、例外がないのは自社に関係する統制目的か、他の顧客向けのサービスに関するものかを確認します。例外事項がある場合は、件数と母集団の大きさ、受託会社経営者の回答（原因と対応）を読みます。
例えば「変更管理：40件のサンプルのうち2件で本番移行前の承認記録が確認できなかった」という例外があったとします。ここで問うべきは、その2件の変更が自社の利用する機能に影響したか、代わりに自社で検知できる統制（例えば、月次の出力結果の照合）があるか、です。例外そのものより、自社の財務報告にとってのリスクがどれだけ残るかに焦点を当てます。
SOC報告書評価調書の記入例
架空のモデルケースとして、A社がクラウドERPのSOC1 Type2を評価した調書の要約を示します。
| 項目 | 記載内容 |
|---|---|
| 報告書 | SOC1 Type2（ISAE 3402およびSSAE 18準拠）、対象期間：前年10月1日〜当年9月30日 |
| 自社会計期間 | 当年4月1日〜翌年3月31日（カバー率：6か月／12か月） |
| 意見 | 無限定意見 |
| 範囲 | 自社が利用する会計・販売モジュール、東京リージョンを含む。データセンター事業者はカーブアウト |
| 例外事項 | 変更管理で2件（承認記録の欠落）。受託会社は承認手続をシステム化済みと回答。自社利用機能への影響なしを確認（リリースノートと照合） |
| CUEC | 7項目。うち5項目は既存の自社統制（ID-01〜03、CHG-02、OPS-01）に対応。2項目（APIキー管理、エクスポートデータの保管）は新たに統制を設定 |
| 再委託先 | データセンター事業者のSOC2 Type2を入手。物理アクセスと環境管理に例外なし |
| ギャップ期間 | 10月〜3月は受託会社のブリッジレター（重要な変更なし）を入手し、自社で月次の残高照合（OPS-04）の運用を追加確認 |
| 結論 | 受託会社の統制は、自社の財務報告に係る評価の代替手段として十分な証拠を提供していると判断 |
このように「読んだ結果、自社として何を判断したか」まで書くことで、監査人のレビューに耐える調書になります。調書全般の書き方は監査調書の書き方と保管ルールも参考にしてください。
ブリッジレターの位置づけ
ブリッジレター（ギャップレター）は、SOC報告書の対象期間終了後から利用会社の期末日までの間に重要な変更がなかったことを、受託会社の経営者が述べる文書です。監査人の保証は付いていないため、それだけで期間の空白を埋めることはできません。ブリッジレターに加えて、自社側の補完手続（委託業務結果の検算、残高照合の運用確認など）を組み合わせるのが一般的です。ギャップが長くなるほど補完手続の比重は大きくなります。
よくある失敗と対策
失敗1：SOC報告書を入手して保管するだけ
最も多いのが、報告書のPDFを共有フォルダに置いたまま評価を終えたことにしてしまうケースです。実施基準が求めるのは、報告書が十分な証拠を提供しているかの「検討」です。対策は、前章の6つのチェックポイントを評価調書のテンプレートにし、毎年同じ形式で記録することです。
失敗2：CUECを読んでいない
CUECは、受託会社監査人の意見の前提条件です。CUECを自社で実施していなければ、報告書の結論を自社に当てはめることはできません。CUECを自社のRCM（リスク・コントロール・マトリクス）に取り込み、統制番号を振って運用テストの対象にすると漏れを防げます。RCMへの反映方法はRCMの記入例で解説しています。
失敗3：SOC2やSOC3で代替して対応づけをしていない
SOC1が提供されていないSaaSは珍しくありません。その場合にSOC2を入手するのは合理的ですが、SOC2の統制と自社のITGC・財務報告リスクとの対応表を作らずに「SOC2があるので問題なし」とするのは危うい判断です。SOC3は詳細なテスト結果が記載されないため、評価の証拠としては限定的です。
失敗4：自社が設定した部分を評価範囲から外している
SaaSでも、承認ルートやマスタの設定、権限ロールの付与は自社の作業です。「SaaSだからベンダーの責任」と考えて評価範囲から外すと、実際に誤りが起きやすい設定変更の領域が無統制になります。
失敗5：クラウドの「知らないうちの変更」を追っていない
事業者のバージョンアップで帳票の出力仕様が変わる、といった変化は自社の変更管理の網にかかりません。リリースノートの確認担当者と、財務影響の判断手順を決めておくことが対策です。
よくある質問
Q1. SOC報告書が提供されていないクラウドサービスはどう評価すればよいですか？
実施基準が示すもう一つの方法、すなわち委託業務の結果を自社で検証する方法（サンプリングによる検証）を中心に考えます。例えば、SaaSが計算した結果を自社で再計算する、入力データと出力データの件数・金額を照合する、といった手続です。あわせて、ISO/IEC 27001などの第三者認証やセキュリティに関する質問票の回答を入手することもありますが、これらは財務報告の統制を直接保証するものではない点に注意が必要です。どの程度で十分とするかは、監査人と早めに協議することをお勧めします。
Q2. SOC報告書の対象期間が自社の会計期間と3か月しか重ならない場合は？
カバー率が低い場合、SOC報告書だけでは運用状況の評価として不十分と判断されることがあります。受託会社が年2回の報告書を発行していれば両方を入手する、ブリッジレターに加えて自社側の補完手続を厚くする、などの対応を組み合わせます。十分性の判断は最終的に自社と監査人の判断になります。
Q3. SOC報告書の例外事項が見つかったら、自社の不備になりますか？
直ちに自社の不備になるわけではありません。例外が自社の利用するサービスに関係するか、自社側に同じリスクを捉える統制があるかを検討し、財務報告に影響する可能性を評価します。影響がないと判断した根拠を調書に残しておくことが大切です。
Q4. 内部監査部門だけでSOC報告書を評価できますか？
英文の報告書やIT固有の論点が多いため、情報システム部門と協力して読むのが現実的です。内部監査部門は評価の観点と結論の妥当性に責任を持ち、技術的な内容の解釈はIT部門の知見を借りる、という役割分担が考えられます。自社のITGC全体の成熟度は、まずITGC簡易診断で把握してから着手すると優先順位を付けやすくなります。
まとめ
ITGCは、自動化された統制の効きめを期間全体に延ばすための土台です。クラウドやSaaSに移行しても、評価の責任は自社に残ります。変わったのは評価の方法で、受託会社側はSOC報告書で、自社側は自社のITGCとCUECのテストで、その継ぎ目はブリッジレターと補完手続で埋める、という三段構えが基本形になります。
次の一歩としては、まず自社が利用するシステムの一覧に「形態」「受託会社の統制の評価方法」「自社で評価する統制」の3列を追加し、空欄をなくすことから始めてみてください。現状の弱点はITGC簡易診断で、4領域17設問から確認できます。関連記事として、ITACとITGCの違い、アクセス管理の監査手順、サイバーセキュリティ監査の進め方もあわせてご覧ください。
ITGC評価やSOC報告書の読み込みについて支援が必要な場合は、お問い合わせからご相談ください。
参考資料
- 金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」（2023年4月7日）https://www.fsa.go.jp/news/r4/sonota/20230407/20230407.html
- 金融庁「内部統制報告制度に関するQ&A」
- 経済産業省「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」（2024年12月25日）
- 日本公認会計士協会 保証業務実務指針3402「受託業務に係る内部統制の保証報告書に関する実務指針」
- 日本公認会計士協会 保証業務実務指針3850「情報セキュリティ等に関する受託業務のTrustに係る内部統制の保証報告書に関する実務指針」
- AICPA「SSAE No. 18」、Trust Services Criteria
- IAASB「ISAE 3402 Assurance Reports on Controls at a Service Organization」
