上場準備に入って1年目の秋、監査法人との打ち合わせの最後に「会計システムと経費精算のSOC1レポートを入手しておいてください」と言われます。経理責任者がベンダーの担当営業に頼むと、秘密保持の確認を経て、数十ページの英語まじりのPDFが届きました。表題には「受託業務に係る内部統制の保証報告書」とあります。ページ数などの数字は仮のものですが、クラウドの会計システムを使う上場準備会社なら、どこかで同じ場面に出会うはずです。
PDFはフォルダに保存され、監査法人には「入手しました」と返信して終わります。実務ではこの流れがよく見られます。ところが、報告書を手に入れただけでは、自社の内部統制の評価は1歩も進みません。報告書には、ベンダーが前提にしている「利用する会社の側でやってほしい統制」が書かれていて、それを自社が実施しているかどうかは、別に確かめる必要があるからです。対象期間が会計期間と半分しか重ならないこともあれば、自社が使っている機能が報告書の対象に入っていないこともあります。
この記事は、SOC1レポートを入手した経理責任者と内部監査担当が、どの順番で何を読み、自社で何を整えるかをまとめたものです。SaaSを使う環境で自社に残るIT全般統制の全体像はSaaSで経理を回す会社に残るITGCの記事、自動化された統制の評価は承認フローや自動仕訳をITACとして評価する記事、上場準備の期ごとの進め方はIPO準備のJ-SOXロードマップの記事で扱い、ここではSOC1レポートの読み方と、その後の手当てに絞ります。
SOC1レポートは、クラウドサービスに委ねた業務の統制を、自社の内部統制の評価に使うための材料です。実施基準は、委託業務の評価の方法として、自社でサンプルを検証する方法と、受託会社の報告書を使う方法を例に挙げ、報告書を使う場合は十分な証拠かどうかを経営者が検討するよう求めています。読む順番は、対象サービスと機能、タイプ（頼れるのは運用まで見たType2）、対象期間、監査人の意見、テスト結果と例外、利用者側で求められる統制（相補的な内部統制）、再委託先の扱いの7項目です。報告書の期間外は前後の期間の報告書、ブリッジレター、自社の監視で補います。報告書の対象外の機能は、残高照合などで結果を自社で検証する方法を軸にし、設定変更とログのレビューを添えます。最後に、相補的な内部統制と自社統制の対応表を作り、報告書の入手を毎年の計画に入れます。
この記事の要約
SOC1レポートは、委託先の統制を自社の評価に使うための材料
金融庁の実施基準は、委託業務も経営者の評価の範囲に入ると書いています。委託業務が企業の重要な業務プロセスの一部を構成している場合、経営者は受託会社の業務について、その内部統制の有効性を評価しなければなりません。委託の例には、取引の記録や集計の委託だけでなく、情報システムの開発・運用・保守などITに関する業務の委託も挙がっています（実施基準 II.2(1)②イ）。クラウド会計や経費精算SaaSに仕訳や承認の記録を任せているなら、この「委託業務」として扱うのが出発点です。
評価のやり方の例として、実施基準は2つの方法を挙げています（実施基準 II.2(1)②ロ）。原文は「以下の手続のいずれかにより内部統制の有効性を評価することも考えられる」という書き方で、この2つに限る趣旨ではありません。
| 方法 | 実施基準の書き方 | クラウド会計に当てはめた例 |
|---|---|---|
| a サンプリングによる検証 | 委託業務結果の報告書と基礎資料との整合性を検証し、結果の一部を企業内で実施して検証する | 銀行明細とクラウド会計の残高を照合し、抽出した仕訳を証憑から再計算する |
| b 受託会社の評価結果の利用 | 受託会社から評価結果を記載した報告書等を入手し、自らの判断で評価の代替手段とする。報告書等が十分な証拠を提供しているかどうかを検討する | ベンダーのSOC1レポートを入手し、対象範囲・期間・結果を読んで、自社の評価に使えるかを判断する |
SOC1レポートは、表の b にあたる「報告書等」の代表です。ただし実施基準は、報告書を入手すれば足りるとは書いていません。「十分な証拠を提供しているかどうかを検討しなければならない」とあり、その検討の中身が、この記事で扱う7項目です。報告書を読まずに保管しただけでは、b の方法を使ったことにならないと考えておくのが安全です。
監査人が報告書のどこを見るかを先に知っておく
監査人の側にも、同じ報告書を読む決まりがあります。内部統制監査では、監査人は企業が受託会社の業務に対して実施している統制を理解し、企業が入手した報告書が十分な証拠を提供しているかを検討します（実施基準 III.4(2)③）。財務諸表監査では、日本公認会計士協会の監査基準報告書402「業務を委託している企業の監査上の考慮事項」に沿って検討します。
クラウドサービスの扱いは、監査基準報告書315の実務ガイダンス第1号 Q30 に書かれています。要点は次の4つです。
- クラウド会計システム等のクラウドサービスも委託業務に該当し、監査基準報告書402に従って評価する
- 自社で保有するシステムとの違いやリスクを考えずに、市販の簡易なパッケージ・ソフトウェアとして評価しないよう注意する
- システムの管理者権限をクラウド業者が持つ場合、不適切なアクセスのリスクに対するIT全般統制をどう理解・評価するかが課題になる
- クラウド業者への往査は他の利用者への守秘義務で制限されることが多く、対応としてタイプ2の報告書の入手が考えられる
このQ&Aは監査人向けの文書ですが、上場準備会社にとっては「監査人がSOC1レポートに何を期待しているか」を知る手がかりになります。監査人は、報告書の対象期間が適切か、報告書に書かれた利用者側の統制が会社に当てはまり、実際に動いているか、テストの手続と結果が会社の財務諸表に関係するかを評価します（監査基準報告書402 第16項）。会社が同じ観点で先に読んでおけば、監査人との協議は「入手したかどうか」ではなく「どう使うか」から始められます。
SOC1とSOC2、Type1とType2は何が違うか
SOCレポートは、もともと米国公認会計士協会（AICPA）の分類です。日本公認会計士協会の保証業務実務指針3000 実務ガイダンス第5号（旧 IT委員会研究報告第55号）の Q1 は、SOC1・SOC2と国内の実務指針の対応関係を示しています。これに同ガイダンス Q10 と各実務指針の想定利用者の定めを合わせて整理すると、次のとおりです。
| 分類 | 主題 | 国内の実務指針 | 想定する利用者 |
|---|---|---|---|
| SOC1 | 財務報告に係る内部統制 | 保証業務実務指針3402「受託業務に係る内部統制の保証報告書に関する実務指針」 | 委託会社と委託会社監査人を想定（報告書にその旨が書かれる） |
| SOC2 | Trustサービス規準に係る内部統制（情報セキュリティ等） | 保証業務実務指針3702「情報セキュリティ等に関する受託業務のTrustに係る内部統制の保証報告書に関する実務指針」（旧 保証業務実務指針3850） | 委託会社、予想される委託会社、委託会社監査人、委託会社または受託会社に係る規制当局 |
違いの軸は、財務報告に係るかどうかです。保証業務実務指針3402は、委託会社の財務報告に関連する業務だけを対象にし、報告書には利用者として委託会社と委託会社監査人のみを想定している旨が書かれます（同 第52項(5)）。ただし、それ以外の者の利用を禁じる趣旨ではなく、受託会社のシステムが財務報告にどう使われているかを十分に理解している者が、自らの判断で使うことも考えられています（保証業務実務指針3000 実務ガイダンス第4号 Q12）。J-SOXと財務諸表監査で前提になるのはSOC1です。SOC2は財務報告の統制目的を対象にしていないため、そのままSOC1の代わりにはなりにくく、使えるとしても一部のIT全般統制の参考資料にとどまります。どこまで使えるかは監査法人と協議してください。
表の3702に旧番号を添えたのは、2022年10月13日付で、保証業務実務指針3850が3702に番号を変えているためです。同じ日付で、IT委員会実務指針第7号も廃止されています。古い解説を読むときは、基準の名前と番号に注意してください。
タイプの違いは、何を保証しているかです。
| タイプ | 保証の対象 | 運用の証拠になるか |
|---|---|---|
| Type1（タイプ1の報告書） | 基準日現在の、統制のデザイン（設計）と業務への適用 | ならない。監査基準報告書402 A20 は「運用状況の有効性に関しては何も証拠を提供しない」と書く |
| Type2（タイプ2の報告書） | 特定期間にわたるデザインと運用状況の有効性。受託会社監査人の運用評価手続とその結果の記述を含む | なる。ただし期間と手続の中身しだい |
J-SOXの運用状況の評価で、ベンダー側の統制の運用の証拠として使えるのはType2です。Type1は、統制がどう設計されているかを理解する材料にはなりますが、期間を通じて動いていたかの証拠にはなりません。Type1しかないサービスを重要な業務に使っているなら、ベンダー側の統制の運用には頼れない前提で、そのサービスが出す結果を自社で検証する量を増やす計画にします。2つのタイプの違いを図にまとめます。
もう1つ、報告書の言葉にも注意が要ります。国内のベンダーでも、報告書は米国の SSAE18 や国際基準の ISAE3402 に準拠して作られていることがあり、freee の2019年の発表も「SSAE18 及び ISAE3402 に準拠」と書いています。その場合、報告書の中の言葉は英語のままだったり、保証業務実務指針3402 と違う言い方だったりします。この記事は国内の3402 の用語で説明しているので、報告書の中で同じ役割の箇所を探しながら読んでください。
読む順番は7項目。最初の3つで「使えるかどうか」を決める
Type2の報告書は、受託会社監査人の保証報告書、受託会社確認書（受託会社が自ら統制を表明する書面）、受託会社のシステムに関する記述書、運用評価手続とその結果の4つで組み立てられています（Type1には運用評価手続とその結果がありません）。頭から順に読むと、記述書の説明で力尽きてしまいます。筆者が勧めるのは、次の7項目を順に確かめる読み方です。基準が順番を定めているわけではありませんが、前の項目で「使えない」と分かれば、後ろを読む手間を省けます。
1つ目は、対象のサービスと機能です。報告書の記述書には、対象とする業務と統制目的が書かれています。同じベンダーでも、製品ごとに報告書の範囲が違うことがあります。自社が使う製品と機能（仕訳の登録、承認、締め、連携など）を一覧にし、記述書の対象に入っているかを1つずつ照らします。
2つ目はタイプ、3つ目は対象期間です。タイプは前の節のとおりで、表題と意見の文言で確かめます。対象期間は、報告書の表題や意見に書かれた「特定期間」です。自社の会計期間と並べ、何か月重なっているかを数えます。期間のずれの扱いは後の節で詳しく書きます。ここまでの3項目で、報告書を自社の評価にどこまで使えるかの大枠が決まります。
監査人の意見と、テスト結果の例外を読む
4つ目は、受託会社監査人の意見です。重要な問題がなければ、記述書が適正に表示されていること、統制が適切にデザインされていること、Type2なら有効に運用されていたことについて、合理的な保証を与える意見が書かれます。問題が重要なら除外事項付意見になり、その程度に応じて限定意見、否定的意見、意見不表明のどれかになります。除外事項付意見のときは、理由がすべて別の区分に書かれます（保証業務実務指針3402 第54項）。
5つ目は、テスト結果と例外です。Type2の報告書には、どの統制にどんな運用評価手続を実施したか、全件か抽出か、その結果が書かれます。逸脱（統制が決められたとおりに動かなかった事例）を見つけた場合は、サンプル数、逸脱の数と内容が書かれ、統制目的は達成されていたと結論づけた場合でも記載されます（同 第53項）。意見に除外事項がなくても、テスト結果の表に例外が載っていることはあります。
| 読む場所 | 確かめること | 自社でやること |
|---|---|---|
| 意見の区分 | 除外事項付意見（限定・否定的・不表明）かどうか。理由の区分 | 除外事項の原因が自社の使う機能に関係するかを判断し、関係するなら監査法人と協議する |
| テスト結果の表 | 例外（逸脱）の有無、件数、サンプル数 | 例外のあった統制が、自社の重要な勘定や業務に関係するかを確かめる |
| 受託会社の回答 | 例外への受託会社の説明や対応 | 対応後の状態を、ブリッジレターや次の報告書で確かめる予定を立てる |
例外が1件あったからといって、報告書が使えなくなるわけではありません。監査基準報告書402 A36 は、例外事項や除外事項付意見があっても、報告書が有用でなくなることを自動的に意味するわけではなく、例外を生じさせた事項を評価の中で検討すると書いています。実務では、例外の内容と自社への影響を1行ずつメモにし、監査法人と共有しておくと話が早く進みます。
利用者側で求められる統制（相補的な内部統制）を、自社の統制と1つずつ対応づける
6つ目が、この記事でいちばん時間をかけてほしい項目です。基準上は「委託会社の相補的な内部統制」と呼ばれ、受託会社が受託業務をデザインする段階で、委託会社において整備されることを想定する内部統制で、統制目的の達成に必要なものとして記述書に記載されるもの、と定義されています（監査基準報告書402 第7項(3)、保証業務実務指針3402 第8項(3)）。英語の報告書では Complementary User Entity Controls を略して CUEC と書かれることが多く、実務でもこの呼び方がよく使われます。
記述書が相補的な内部統制を前提にしている場合、保証報告書には、受託会社監査人が相補的な内部統制のデザインや運用を評価していないこと、そして受託会社の統制に加えて相補的な内部統制が有効に機能している場合にのみ統制目的が達成されることが書かれます（保証業務実務指針3402 第52項(3)③）。つまり、ベンダーの統制がすべて有効でも、利用者側の統制が動いていなければ、報告書が保証する統制目的は自社では達成されません。監査人は、記述書に書かれた相補的な内部統制が会社に当てはまるかを判断し、当てはまれば会社がそれを設計して運用しているかを確かめます（監査基準報告書402 第16項(2)）。整備されていなければ、監査人が不備として報告することもあります（同 A37）。
クラウド会計や経費精算の報告書で、相補的な内部統制として書かれやすいのは次のような領域です。実際の文言は報告書ごとに違うので、あくまで例として読んでください。
- 利用者IDの発行・変更・削除と、権限の付与を委託会社が承認し、定期的に見直すこと
- 管理者権限を持つ利用者を委託会社が限定すること
- 委託会社が登録・連携するデータについて、正確性と網羅性を自ら確かめること
- 承認経路や自動化のルールなど、委託会社が行う設定の変更を自ら管理すること
- 出力されたレポートや残高を、委託会社が照合・レビューすること
利用者IDの発行と削除の流れは、FDEを迎える前に情シスが用意するもので書いたアカウント発行の順番と退場手順がそのまま使えます。相補的な内部統制の多くは、SaaSの環境で自社に残るIT全般統制と重なります。全体像はSaaSで経理を回す会社に残るITGCの記事を参照してください。相補的な内部統制の位置づけと、後で作る対応表のこつを1枚にまとめます。
再委託先の扱い（一体方式と除外方式）を確かめる
7つ目は、再委託先の扱いです。SaaSのベンダーは、データセンターやクラウド基盤を別の事業者に任せていることが多く、基準上はこれを「再受託会社」と呼びます。報告書での扱いには2つの方式があり、保証報告書には再受託会社が行う業務の内容と、どちらの方式かが書かれます（保証業務実務指針3402 第8項(4)(16)、第52項(3)④）。
| 方式 | 報告書での扱い | 利用する会社への影響 |
|---|---|---|
| 一体方式 | 再受託会社の統制目的と統制が、記述書と受託会社監査人の業務の範囲に含まれる | 再受託会社の部分も、この報告書で確かめられる |
| 除外方式 | 再受託会社の業務は記述書に書かれるが、その統制目的と統制は記述書と受託会社監査人の業務の範囲から除かれる | 再受託会社の部分は、この報告書では保証されていない |
除外方式のときは、再受託会社の業務が監査に関係するなら、監査人は再受託会社についても監査基準報告書402の要求事項を適用します（同 第17項、A38）。会社としては、クラウド基盤の事業者が公表しているSOCレポートの入手を求められる場合に備えておきます。また、除外方式でも、ベンダーが再受託会社の統制を監視する統制は、記述書と受託会社監査人の業務の範囲に入ります。その監視には、ベンダーが再受託会社の保証報告書を入手して検討することが含まれる場合があります（保証業務実務指針3402 第8項(16)）。その監視の統制がテストされているかも、あわせて読みます。
この項目は、報告書の最後のほうに短く書かれていることが多く、読み飛ばされがちです。監査法人から追加の依頼が来てから慌てないよう、方式と再受託会社の名前を、6つ目の対応表と同じシートに書き留めておくことを勧めます。
対象期間が会計期間とずれているときは、前後の報告書、ブリッジレター、自社の監視で補う
SOC1レポートの対象期間は、自社の会計期間とぴったり重なることのほうが珍しいものです。保証業務実務指針3000 実務ガイダンス第4号も、保証報告書の対象期間は委託会社の会計期間と何か月かずれていることが多いと書いています（Q13の解説）。たとえば、対象期間が2024年7月1日から12月31日の報告書を、3月決算の会社が2024年4月から2025年3月の事業年度に使う場合を考えます。
| 区分 | 期間 | 月数 |
|---|---|---|
| 会計期間 | 2024年4月〜2025年3月 | 12か月 |
| 報告書が覆う期間 | 2024年7月〜12月 | 6か月 |
| 期首側の空白 | 2024年4月〜6月 | 3か月 |
| 期末側の空白 | 2025年1月〜3月 | 3か月 |
| 空白の合計 | 12か月 − 6か月 | 6か月 |
監査基準報告書402 A30 は、対象期間が短いほど、またテストの実施から時間がたつほど、得られる証拠は少なくなるとし、依拠したい期間との重なりが僅かなら、報告書が提供する証拠は少ないと結論づけることがあるとしています。対象期間が会計期間の完全に外にある場合は、他の手続を実施しない限り、その報告書のテストに依拠できません（同 A33）。一方で、対象外の期間に対象期間内とまったく同じ証拠が必ず求められるわけではなく、追加の証拠の範囲は監査人が空白の長さやリスクの程度などを考えて決めます（同 A31、実務ガイダンス第4号 Q15）。上の例のように半分が空白なら、何で補うかを期首のうちに監査法人と決めておくのが現実的です。
最も基本的な補い方は、前後の期間を対象にした別のType2の報告書です。監査基準報告書402 A30 は、前の期間や後の期間を対象とするタイプ2の報告書が追加の証拠になることがあるとし、監査人が受託会社で自ら運用評価手続を実施するか、それを実施する他の監査人を利用する必要があると判断することもあると書いています。上の例なら、期首側の4〜6月は前の期間の報告書で補えることがあります。
期末側の空白を補う材料の1つが、ブリッジレター（ロールフォワード・レターとも呼ばれます）です。実務ガイダンス第4号 Q15 によると、これは報告書の対象期間の末日から委託会社の会計期間末日までの状況を把握するために、タイプ2の報告書に関連して受託会社が発行する書面で、通常、対象期間の最終日以降に統制環境や内部統制に重要な変更があったかどうかが書かれます。扱うのは期末側だけなので、上の例では1〜3月はブリッジレター、4〜6月は前の期間の報告書か自社の監視、と分けて考えます。ブリッジレターは受託会社が自ら書く書面で、受託会社監査人の保証報告書ではありません。実務ガイダンス第4号は、報告書に開示された後発事象についても、受託会社監査人は有無を質問しているだけで、運用評価手続はしていないと注意を促しています。
そのため、ブリッジレターだけで空白が埋まるとは考えないほうが安全です。監査基準報告書402 A32 は、追加の証拠の例として、受託会社の統制を監視する委託会社のプロセスをテストすることを挙げています。自社でできる監視には、ベンダーが公表する障害、リリース、セキュリティインシデントの情報を毎月確かめて影響を記録することや、出力された残高を照合して異常がないかを確かめることがあります。相補的な内部統制は空白の期間も止めずに運用しますが、これは自社側の統制の証拠で、ベンダー側の統制が空白の期間に動いていた証拠にはなりません。上の例の空白と、それぞれの補い方を図にまとめます。
報告書の対象外の機能は、結果の検証を軸に自社で補う
1つ目の項目で、自社の使う機能が報告書の対象に入っていないと分かることがあります。報告書の取得後にリリースされた製品や、Type1までしかない製品を使っている場合も同じです。そのときは、実施基準 II.2(1)②ロ の a のように、委託業務の結果を自社で検証する方法（残高照合や、抽出した取引の再計算）を軸にします。あわせて、自社が管理できる範囲の設定変更とログもレビューします。ただし、これらはベンダー側の統制（プログラムの変更管理やインフラの運用など）そのものの代わりにはなりません。SaaSの自動計算や帳票にどこまで依拠するかは、監査法人と協議して決めます。
自社で置く統制は、次の3つに分けると分かりやすいと筆者は考えています。a に当たるのは1行目の残高照合で、2行目と3行目は利用者側のIT全般統制です。頻度や証跡の残し方は例で、どこまで求められるかは監査法人と協議して決めてください。
| 自社で置く統制 | 何を確かめるか | 頻度と証跡の例 |
|---|---|---|
| 残高照合 | SaaSが出した結果が正しいか。銀行残高、カード明細、売掛金の補助簿とクラウド会計の残高を突き合わせる | 月次。照合表に差異の理由と照合者・承認者を残す |
| 設定変更のレビュー | 承認経路、自動登録のルール、勘定科目の対応づけ、連携設定などが、承認なく変えられていないか | 月次または四半期。変更の一覧と、変更申請との突合の記録を残す |
| ログのレビュー | 誰がいつ何をしたか。管理者権限の操作、締め後の修正、権限の変更に異常がないか | 四半期。ログを社内に退避し、レビューの結論を記録する |
3つの統制の役割を図にすると次のとおりです。
残高照合は、月次の締めの手順に組み込むと続けやすくなります。締めの段取りは経理業務を FDE 方式で本番化する記事で書いた月次締めの流れが参考になります。設定変更の申請と承認の残し方は引き継ぎの記事の変更手順、ログの保存場所と権限の考え方はデータの扱い6項目の記事が手がかりになります。
ログのレビューで注意したいのは、使える機能がプランで変わることです。操作ログや権限変更の履歴が上位のプランにしかないサービスもあります。ログが取れないなら、残高照合と設定変更のレビューを厚くするなど、組み合わせで補う設計にします。自動化された統制の評価の考え方は承認フローや自動仕訳をITACとして評価する記事を参照してください。
freee・バクラクの公表状況（2026年10月時点）
2026年10月時点で公表されている情報では、両社のSOC1レポートの状況は次のとおりです。いずれも各社の公式発表とWebサイトの記載で、報告書の本体ではありません。
| サービス | 公表されている内容 | 出典 |
|---|---|---|
| freee会計 | SOC1 Type2を受領。2019年3月5日発行、基準期間は2018年4月1日〜12月31日（最初の発表）。製品サイトは、エンタープライズプランの利用者が報告書を利用できると記載 | freee 2019年3月5日発表、freee 内部統制の紹介ページ |
| freee請求書、freee経理 | 受領済みと記載（タイプは発表文に明記なし） | フリー 2025年6月2日発表 |
| freee人事労務、freee販売、freee支出管理、freee工数管理 | SOC1 Type1を受領。今後Type2の受領を目指すと記載 | フリー 2025年6月2日発表 |
| バクラク経費精算、申請、請求書受取、ビジネスカード、電子帳簿保存、請求書発行 | SOC1 Type2を取得。2025年3月27日発行、基準期間は2024年7月1日〜12月31日 | LayerX 2025年4月8日発表 |
| バクラク勤怠、バクラク債権管理 | 上記の報告書の対象外（審査プロセス後のリリースのため） | LayerX 2025年4月8日発表 |
バクラクの発表文には、Type2としながら「基準日時点における内部統制のデザインの評価に関する保証報告書です」という一文もあります。基準期間が書かれていることからType2と読めますが、タイプは発表文ではなく、入手した報告書の表題と意見で確かめてください。
これより新しい基準期間の報告書を公表した公式発表は、2026年10月4日時点で見つかりませんでした。バクラクのセキュリティページはSOC1 Type2の取得を掲載していますが、基準期間は書かれていません。報告書は基準期間ごとに発行されるものなので、最新の基準期間と対象サービスは、入手のたびにベンダーへ確かめる必要があります。
窓口は、バクラクは発表の中で「商談中・ご契約中のお客様は担当営業まで」と案内しています。freeeは、2019年の発表で報告書の請求窓口を案内していましたが、いまの窓口と条件は筆者は確認できなかったため、担当営業かサポートに問い合わせてください。SOC1の報告書は委託会社とその監査人が使うことを想定して作られているので、秘密保持の手続を求められることがあります。表の内容は発表時点のもので、プランの条件や対象サービスは変わりうるので、契約前と毎期の入手時に確認してください。
相補的な内部統制と自社統制の対応表のひな型
6つ目の項目で読んだ相補的な内部統制は、表にして自社の統制と1対1で結びつけます。筆者が勧める列は次のとおりです。行の記載は説明のための仮の例で、実際の報告書の文言ではありません。
| 報告書の統制目的 | 相補的な内部統制（報告書の文言を転記） | 自社に当てはまるか | 自社の統制（RCM上の番号） | 実施者と頻度 | 証跡 | 運用評価の結果 |
|---|---|---|---|---|---|---|
| 例 論理アクセス | 利用者の追加・変更・削除は利用会社が承認する | 当てはまる | IT-AC-01 ID申請と承認 | 情報システム担当、都度 | 申請票と承認記録 | 25件中逸脱0件 |
| 例 論理アクセス | 利用会社は利用者と権限を定期的に見直す | 当てはまる | IT-AC-03 権限の棚卸 | 経理責任者、四半期 | 棚卸表と承認 | 4回中逸脱0件 |
| 例 データの入力 | 利用会社は連携データの正確性を確かめる | 当てはまる | FC-05 連携件数・金額の突合 | 経理担当、月次 | 突合表 | 未実施 |
| 例 外部連携 | 利用会社はAPI連携の設定を管理する | 当てはまらない（API連携を使っていない） | なし | なし | なし | 対象外とした理由を記録 |
表の作り方のこつは3つあります。1つ目は、報告書の文言を要約せずに転記することです。言い換えると、監査人と照らし合わせるときに対応が分からなくなります。2つ目は、「当てはまらない」と判断した行も消さずに、理由を残すことです。3つ目は、リスクと統制の対応表（RCM）の番号で自社の統制を指すことです。RCMを含む文書化の進め方はIPO準備のJ-SOXロードマップの記事で扱います。
この表は、報告書が更新されるたびに作り直します。相補的な内部統制の文言は、ベンダーの機能追加や体制の変更で毎期変わりうるからです。新旧の報告書を並べ、増えた行と消えた行を確かめるところまでを、毎年の作業にしておきます。
筆者たちが最初に誤解していたこと、うまくいかない読み方
SOC1レポートの周りは、基準の番号が2022年に変わり、用語も国内の実務指針と米国の基準で揺れているため、調べる側も誤りやすい分野です。
この記事は、書き上げたあとに一次資料を取り直し、誤りがある前提で読み直しています。そこで直した点のうち、報告書を読む人が同じように誤りそうなものを5つ残します。左の列は直す前の筆者たちの理解で、右の列は日本公認会計士協会の公表物と実施基準の原文で確かめ直した内容です。
| 筆者たちが最初に考えていたこと | 実際は | 根拠 |
|---|---|---|
| 「SOC2の実務指針は保証業務実務指針3850、SOCの対応表はIT委員会研究報告第55号を引けばよい」 | 2022年10月13日に名称と番号が変わり、3850は保証業務実務指針3702、研究報告第55号は保証業務実務指針3000 実務ガイダンス第5号になっています | 日本公認会計士協会「委員会職務分掌変更等に伴う旧IT委員会公表物の名称・位置付けの変更について」 |
| 「ブリッジレターがあれば、期首側と期末側の両方の空白が埋まる」 | ブリッジレターが扱うのは、報告書の対象期間の末日から会計期間の末日までです。期首側は、前の期間のType2の報告書や自社の監視で補えることがあります。何で補うかは監査法人と決めます | 実務ガイダンス第4号 Q15、監査基準報告書402 A30〜A32 |
| 「空白の期間に相補的な内部統制を回しておけば、ベンダー側の空白も埋まる」 | 相補的な内部統制は自社側の統制で、ベンダーの統制が動いていた証拠にはなりません。402 A32が挙げるのは、ベンダーの統制を監視する自社のプロセスです | 監査基準報告書402 第7項(3)・A32 |
| 「SOC1レポートを使えるのは、委託会社とその監査人に限られる」 | 報告書には両者のみを想定している旨が書かれますが、利用を禁じてはいません。受託会社のシステムが財務報告にどう使われているかを十分に理解していれば、自らの判断で使うことも考えられます | 保証業務実務指針3402 第52項(5)、実務ガイダンス第4号 Q12 |
| 「報告書の対象外の機能は、設定変更とログのレビューを置けばベンダーの統制の代わりになる」 | 実施基準のaは、委託業務の結果を自社で検証する方法です。設定変更とログのレビューは利用者側のIT全般統制で、ベンダー側のプログラム変更管理などの代わりにはならない、というのが筆者の整理です | 実施基準 II.2(1)②ロa（後半は筆者の整理） |
2つ目と3つ目は、どちらも空白の期間を何で埋めるかの取り違えでした。読んだ結果を監査法人と共有するときは、何を使って、どの期間の、誰の統制を補っているのかを1行ずつ書き分けておくと、この種の取り違えに早く気づけます。
明日からやること
SOC1レポートの扱いは、入手した日ではなく、入手を年間計画に入れた日から始まります。評価の年度に間に合わせるには、どの月に誰が何をするかを先に決めておく必要があります。決めておく項目を一覧にしました。
- 使っているSaaSを一覧にし、製品と機能ごとに、財務報告に関係するか、SOC1レポートがあるか（Type1かType2か）を書く
- 入手の窓口（担当営業、サポート）と、秘密保持の手続、社内の保管場所と閲覧できる人を決める
- 報告書の発行時期をベンダーに確かめ、入手する月を年間計画に入れる。前年の報告書の期間を見れば、次の発行時期の見当がつく
- 入手したら1週間以内に7項目を読み、結果を1枚にまとめて監査法人と共有する
- 相補的な内部統制と自社統制の対応表を作り、当てはまる統制を自社の評価の対象に入れる
- 対象期間の空白を何で補うかを監査法人と決める。対象外の機能は、結果を検証する統制（残高照合など）を軸に、設定変更とログのレビューを添える形を決める。ブリッジレターを出してもらえるかもベンダーに確かめる
- 再委託先が除外方式なら、再受託会社の報告書が必要かを監査法人と協議する
一覧のうち、最初に手をつけるなら1と3です。使っているサービスと報告書の発行時期が分かれば、どの月に何が届き、どの期間が空白になるかが見えます。空白の大きさが分かると、6で置く統制の量も決まります。
どこまでを報告書に頼り、どこから自社の統制で補うかは、監査法人と協議して決める事項です。基準は「十分な証拠かどうかを検討する」とだけ書いていて、決まった答えを示していません。だからこそ、7項目を読んだ結果を会社側から先に示せば、協議の土台を会社が作れます。
IT統制・J-SOX対応の進め方をご相談ください
使っているSaaSの洗い出し、IDと権限・設定変更の記録の始め方、SOC1レポートの読み込み、監査法人との協議に出す案づくりまで、公認会計士とエンジニアが一緒に整理します。