クラウド・SaaS利用時の内部統制とSOC報告書の読み方｜確認ポイントを解説

会計、経費精算、販売管理、人事給与といった財務報告に関わる業務でも、クラウドサービスや SaaS の利用が当たり前になりました。システムを自社で保有しない分、運用の負担は軽くなりますが、内部統制の観点では「サービス事業者側の統制をどう確認するか」「自社側で何をすべきか」という新たな論点が生まれます。SOC報告書を入手しているものの、「受け取って保管しているだけ」「どこを読めばよいか分からない」という声も少なくありません。本記事では、内部統制報告制度（J-SOX）の評価担当者や IT 部門、内部監査部門の方に向けて、クラウド・SaaS 利用時の責任分界の考え方、SOC1・SOC2 報告書の違いと読み方、利用者側で整備すべき統制、報告書が入手できない場合の対応を整理します。

クラウド・SaaS 利用で内部統制が変わる点

自社でサーバーやシステムを運用している場合、ITGC（IT全般統制）の多くは自社の IT 部門が実施し、評価者はその運用状況を直接確認できます。一方、クラウドや SaaS を利用する場合は、統制の一部をサービス事業者が担うことになり、自社では直接確認できない領域が生まれます。

たとえば SaaS の会計システムでは、アプリケーションのプログラム変更、データベースの運用、バックアップ、データセンターの物理的な管理などは、通常サービス事業者が行います。自社から見れば、これらの統制が有効に機能していることを前提に業務を行っていることになり、その前提をどのように確かめるかが評価の論点になります。

財務報告に係る内部統制の評価及び監査に関する実施基準でも、業務を外部に委託している場合、委託業務に関する内部統制についても評価の対象になることが示されています。また J-SOX 2024 改訂では、IT の委託先を含むリスクへの対応が明確化されました。改訂の全体像については「J-SOX 2024改訂のポイント」をご覧ください。

責任分界（責任共有モデル）の整理

クラウドサービスでは、サービスの形態によって、事業者と利用者の責任範囲が異なります。一般的な整理は次のとおりです。

実際の責任範囲はサービスや契約内容によって異なるため、利用規約やサービスレベル合意書（SLA）、事業者が公開している責任共有に関する資料で確認することが必要です。どの形態であっても、アカウントとアクセス権限の管理、入力するデータの正確性、アプリケーションの設定（承認ルートや勘定科目のマッピングなど）は利用者側の責任として残る点が重要です。

財務報告に関係するクラウドサービスについては、サービスごとに「事業者が担う統制」「利用者が担う統制」を一覧にした責任分界表を作成しておくと、評価範囲の説明や監査人との協議がスムーズになります。

SOC報告書とは

SOC報告書は、サービスを提供する受託会社の内部統制について、独立した監査法人等が評価し、その結果を利用者向けにまとめた保証報告書です。利用者は、事業者の統制を自ら直接評価する代わりに、この報告書を入手して内容を確認することで、委託先の統制の有効性を判断する材料とします。

SOC1 と SOC2 の違い

SOC報告書には主に SOC1 と SOC2 があり、目的と対象が異なります。

• SOC1 報告書: 利用者の財務報告に関連する受託会社の内部統制を対象とします。国際的には国際保証業務基準 ISAE3402、米国では SSAE18、日本では日本公認会計士協会の保証業務実務指針3402「受託業務に係る内部統制の保証報告書に関する実務指針」に基づいて作成されます。J-SOX の評価で主に参照するのはこの報告書です。
• SOC2 報告書: セキュリティ、可用性、処理のインテグリティ、機密保持、プライバシーといった観点（トラストサービス規準）に基づき、受託会社の内部統制を対象とします。情報セキュリティや委託先管理の観点での確認に広く用いられますが、財務報告に直接関係する統制が十分に含まれているとは限りません。

J-SOX の評価で SOC2 報告書しか入手できない場合は、財務報告に関係するリスク（アクセス管理、変更管理、処理の正確性など）に対応する統制が含まれているかを個別に確認し、不足する部分は他の手続で補う必要があります。

タイプ1 とタイプ2 の違い

SOC報告書には、評価の範囲によってタイプ1 とタイプ2 があります。タイプ1 は特定の基準日時点における統制の記述と整備状況（デザイン）を対象とし、タイプ2 は一定期間における整備状況に加えて運用状況の有効性を対象とします。J-SOX の運用評価の観点からは、一定期間の運用状況を検証したタイプ2 の報告書を入手することが望ましいとされます。

SOC報告書の読み方

SOC報告書は分量が多く、すべてを同じ深さで読む必要はありません。次の観点を押さえると、効率的に確認できます。

対象範囲と対象期間

まず、報告書の対象となっているサービス、システム、拠点が、自社が利用しているものと一致しているかを確認します。同じ事業者でも、自社が使っているサービスが対象外であれば、その報告書は評価の根拠になりません。あわせて、対象期間が自社の評価対象期間をどの程度カバーしているかを確認します。期間にずれがある場合は、事業者から対象期間終了後に重要な変更がないことを表明する書面（ブリッジレター）を入手するなどの対応を検討します。

監査人の意見

報告書には、受託会社監査人（報告書を作成した監査法人等）の意見が記載されています。統制が有効である旨の意見（無限定意見）か、一部の統制について除外事項が付された意見かを確認します。除外事項がある場合は、その対象となった統制が自社の財務報告に影響するかを検討します。

統制目的と統制の記述

報告書には、受託会社が設定した統制目的と、それを達成するための統制が記載されています。自社が依拠したい統制（プログラム変更、アクセス管理、バックアップ、処理の正確性など）が含まれているかを確認します。

運用テストの結果と例外事項

タイプ2 の報告書では、監査人が実施したテストの内容と結果が記載されています。例外事項（テストで逸脱が見つかったもの）がある場合は、その内容、受託会社の対応、自社への影響を検討し、評価の記録に残します。監査人の意見が無限定であっても、個々の例外事項が自社にとって重要な場合があるため、見落とさないよう注意が必要です。

例外事項を評価するときの進め方

例外事項の検討は、SOC報告書の確認の中でも判断が求められる部分です。次の順序で整理すると、検討の漏れを防ぎ、評価調書にも根拠を残しやすくなります。

1. 関連性の判断: 例外事項の対象となった統制が、自社が依拠している統制目的に関係するかを確認します。関係しない場合は、その旨と理由を記録します
2. 内容の把握: 逸脱の件数、母集団に対する割合、発生時期、原因を報告書の記載から把握します。受託会社の経営者の回答（対応状況）が記載されている場合は、あわせて確認します
3. 補完する統制の確認: 同じ統制目的に対応する他の統制が有効であるか、自社側の統制（CUEC や処理結果の確認）でリスクが低減されているかを検討します
4. 自社への影響の結論: 以上を踏まえ、自社の財務報告に影響を与える可能性を評価し、追加の手続が必要かを判断します

評価調書には、例えば「アクセス権の削除が退職後○営業日以内に行われていない事例が一部検出されている。当社の利用者 ID は当社側で削除を管理しており（CUEC 対応統制 No.○）、当社の運用評価で有効と判断していることから、当社の財務報告への影響はないと判断した」のように、判断の根拠を具体的に記載します。

再委託先の扱い

SaaS 事業者が、基盤としてさらに別のクラウド事業者（再委託先）を利用していることは珍しくありません。報告書が再委託先の統制を含めて評価している方式（一体方式）か、再委託先を評価範囲から除いている方式（除外方式）かを確認します。除外方式の場合は、必要に応じて再委託先の SOC報告書も入手・確認します。

利用者側で整備すべき統制（CUEC）

SOC報告書には、受託会社の統制が有効に機能するために利用者側で実施することが想定されている統制が記載されています。これを相補的な利用者エンティティの統制（CUEC：Complementary User Entity Controls）と呼びます。

CUEC として記載される代表的な例には、次のようなものがあります。

• 利用者の ID の登録・変更・削除を、利用者側の責任で承認・実施すること
• 利用者に付与した権限を定期的に見直すこと
• 利用者側で行う設定変更（承認ルート、マスタなど）を適切に管理すること
• サービスに入力するデータの正確性と網羅性を確認すること
• サービスから出力された結果を確認し、異常があれば事業者に連絡すること

事業者の統制が有効であっても、CUEC が自社で実施されていなければ、全体としての統制は有効とはいえません。CUEC を一覧にし、それぞれに対応する自社の統制を RCM に反映させ、評価の対象とすることが重要です。ITGC の評価方法については「ITGC（IT全般統制）評価の実務」で詳しく解説しています。

責任分界・CUEC 対応表（テンプレート）

責任分界の整理と CUEC への対応状況は、サービスごとに一つの表にまとめておくと管理しやすくなります。以下は項目の例です。

CUEC の中には、「利用者は、自社の従業員の退職時に速やかに ID を無効化する」のように、既存の ITGC ですでにカバーされているものもあります。その場合は、新たな統制を設けるのではなく、既存の統制と対応づけて記録すれば十分です。一方、「利用者は、サービスから出力された処理結果の正確性を確認する」といった CUEC は、業務プロセス側で対応する統制がないことも多く、業務部門と連携して統制を設計する必要があります。

SOC報告書が入手できない場合の対応

利用しているサービスによっては、SOC報告書が発行されていない、または自社の利用範囲が対象外という場合もあります。その場合は、リスクの大きさに応じて次のような代替的な手続を組み合わせて検討します。

• 事業者が公開している第三者認証（情報セキュリティマネジメントシステムの認証など）の取得状況と対象範囲を確認する
• 事業者に質問票を送付し、統制の状況について回答を得る
• 契約書や SLA で、障害時の対応、データの保全、監査への協力などが定められているかを確認する
• 利用者側で、サービスから出力されたデータと入力元の記録を突き合わせるなど、処理結果を検証する統制を強化する

第三者認証や質問票への回答は、SOC報告書と比べると財務報告に係る統制の運用状況までは確認できない場合が多いため、利用者側での処理結果の検証を組み合わせることが実務上のポイントになります。どの手続で十分と判断するかは、評価計画の段階で監査人と協議しておくとよいでしょう。

SOC報告書を評価に組み込む手順

SOC報告書の確認を毎年の J-SOX 評価の中に定着させるには、次のような手順を年間の評価スケジュールに組み込んでおくと効果的です。

1. 対象サービスの棚卸: 財務報告に関係するクラウドサービス・SaaS・外部委託業務を一覧にし、利用している業務プロセスと依拠している統制を整理する
2. 報告書の入手計画: 各事業者の報告書の発行時期と対象期間を確認し、評価スケジュールに間に合うよう入手を依頼する。契約時に報告書の提供を条件に含めておくと入手が円滑になる
3. 報告書の評価: 後述のチェックリストに沿って内容を確認し、例外事項や CUEC への対応を検討する
4. 利用者側統制の評価: CUEC に対応する自社の統制を、他の ITGC や業務処理統制と同様に整備・運用評価する
5. 結果の文書化と共有: 確認結果を評価調書にまとめ、重要な例外事項や未対応の CUEC があれば、IT 部門や業務部門と改善策を協議する

報告書の確認は IT 部門、評価の取りまとめは内部統制推進部門や内部監査部門というように担当が分かれることも多いため、誰がどの段階を担うかを明確にしておくことが大切です。また、新たなサービスの導入時には、契約前の段階で SOC報告書の有無や対象範囲を確認するよう、購買やシステム導入の手続に組み込んでおくと、評価の段階で慌てずに済みます。

SOC報告書の確認チェックリスト

SOC報告書を受領した際の確認事項をチェックリストにまとめました。確認結果は評価調書として記録に残してください。

• 報告書の種類（SOC1 / SOC2、タイプ1 / タイプ2）を確認したか
• 対象となるサービス・システム・拠点が、自社の利用範囲と一致しているか
• 対象期間が自社の評価対象期間をカバーしているか（ギャップがある場合はブリッジレター等を入手したか）
• 監査人の意見の種類（無限定意見か、除外事項付きの意見か）を確認したか
• 自社が依拠する統制目的と統制が含まれているか
• 運用テストの例外事項の内容と、自社への影響を検討したか
• 再委託先の扱い（一体方式か除外方式か）を確認し、必要な対応をとったか
• CUEC を一覧化し、自社の統制として整備・評価しているか
• 前年度の報告書と比べて、対象範囲や統制に重要な変更がないか

よくある質問

Q. SOC報告書の対象期間が自社の決算期と大きくずれている場合、どう対応すればよいですか。

A. 対象期間が自社の評価対象期間の一部しかカバーしていない場合は、ブリッジレターの入手に加えて、カバーされていない期間について利用者側の統制（処理結果の確認や照合など）の運用状況をより重点的に確認することが考えられます。ギャップの期間が長い場合や、その期間にシステムの大きな変更があった場合は、どの程度の追加手続が必要かを監査人と協議します。

Q. 事業者から報告書を受け取るには、どのような手続が必要ですか。

A. SOC報告書は一般に配布先が限定されており、秘密保持契約の締結や、事業者のポータルからの申請を求められることが多くあります。入手に時間がかかる場合もあるため、評価スケジュールから逆算して早めに依頼します。新規契約の際には、報告書の提供を契約条件に含めておくと、毎年の入手が円滑になります。

Q. SaaS で自社が設定した承認ルートや自動計算の設定は、誰が評価するのですか。

A. アプリケーションの設定は利用者側の責任であるため、自社で評価します。承認ルートの設定内容が職務権限規程と整合しているか、設定変更が承認されたうえで行われているか、自動計算や自動仕訳の設定が正しいかを確認します。SaaS に組み込まれた自動化された統制の評価方法は「ITAC（自動化された業務処理統制）の評価」で解説しています。

Q. 財務報告に関係するかどうか判断が難しいサービスはどう扱えばよいですか。

A. サービスから出力されたデータが仕訳や財務数値の算定に使われているか、財務報告に関係する統制の実施にサービスが使われているかを基準に判断します。判断の過程を対象サービスの棚卸表に記録しておくと、翌年度以降の見直しや監査人への説明に役立ちます。財務報告に直接関係しないサービスでも、情報セキュリティや個人情報保護の観点からは SOC2 報告書などで管理状況を確認しておくことが望まれます。

よくある失敗例と対策

SOC報告書の活用でよく見られる失敗と、その対策を整理します。

まとめ

クラウド・SaaS を利用する場合でも、財務報告に係る内部統制の責任が利用者からなくなるわけではありません。責任分界を整理し、事業者が担う統制は SOC報告書などで確認し、利用者が担う統制は自社で整備・評価するという役割分担が基本になります。SOC報告書は受け取って保管するだけでなく、対象範囲、対象期間、意見、例外事項、再委託先、CUEC といった観点で読み込み、例外事項については関連性・内容・補完統制・影響の順に検討して、その結果を評価の記録に残すことが大切です。責任分界・CUEC 対応表でサービスごとの状況を一元管理し、報告書の入手時期を年間スケジュールに組み込んでおけば、よくある失敗も防げます。本記事のチェックリストとテンプレートを活用し、自社で利用しているクラウドサービスの管理状況を点検してみてください。

関連サービス

• IT監査・ITガバナンス支援
• J-SOX（内部統制）評価支援