LASSIC Media らしくメディア
SOC2報告書とは｜SaaSの監査要求への対応
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- SOC2報告書：第三者の監査人が統制の状況について意見を述べる保証報告書で、いわゆる認証とは性格が異なります。
- Type1とType2：Type1は一時点の設計、Type2は一定期間の運用状況までを対象とし、取引先が求めるのは多くの場合Type2です。
- 開発の実務：アクセス管理・変更管理・監視・インシデント対応の手順と、その証跡が残る仕組みづくりが要になります。
※ 本記事は2026年8月時点の公式情報（省庁・公的機関・ベンダー公式ドキュメント）に基づきます。
SaaSを提供していると、大口の商談で「SOC 2の報告書はありますか」と問われる場面が出てきます。委託先を評価する側も、相手のセキュリティ体制をどう確かめるかで頭を悩ませます。SOC 2は、こうしたやりとりの共通言語として使われている仕組みです。
本記事では、SaaSやシステム運用を提供する事業者、そして委託先を評価する立場の担当者に向けて、SOC 2報告書の位置づけ、Type 1とType 2の違い、五つの規準、ISMSやISMAPとの使い分け、そして取得までの流れと開発・運用側で問われる統制を整理します。制度の一般的な整理ですので、実際の対応は監査人や公式資料で確かめながら進めてください。
目次
SOC2とは——「認証」ではなく保証報告書
SOC 2は、サービスを提供する組織の内部統制について、独立した監査人が検証し、その結果を報告書として示す枠組みです*1。ISMSのように「認証を取得してロゴを掲げる」形とは性格が違い、成果物は監査人の意見を含む報告書になります。だからこそ、取引先に提出して中身を読んでもらう使い方が前提になるのです。
この違いは実務にも影響します。認証であれば「取得済みかどうか」で話が進みますが、報告書は範囲と期間、そして例外事項（統制が働かなかった事例）まで読まれます。範囲に含めていないサービスや、観察期間の外側は、報告書では何も語られません。したがって「SOC 2があります」と答えるだけでは足りず、どの範囲・どの期間の報告書なのかを示す必要が出てきます。
報告書は原則として、求めた相手に限って共有する性格のものです。誰にでも公開できる要約版としてSOC 3が用意されており、Webサイトなどで示したい場合はこちらを使う形になります。営業活動で広く見せたいのか、個別の商談で開示したいのかによって、必要な成果物が変わってくるわけです。
Type1とType2、SOC1・SOC3との違い
混同されやすい区分を整理しておきましょう。SOCという名前を共有していても、目的の異なる報告書が並んでいます*1*2。
| 種類 | 対象 | 答える問い |
|---|---|---|
| SOC 1 | 財務報告に関わる統制 | 委託先の処理が、利用企業の財務報告の信頼性を損なわないか |
| SOC 2 Type 1 | セキュリティなどの統制（一時点） | ある時点で、統制の設計は適切に整えられているか |
| SOC 2 Type 2 | セキュリティなどの統制（一定期間） | その期間を通じて、統制は実際に機能していたか |
| SOC 3 | SOC 2の要約 | 広く公開できる形で、概要を示せるか |
取引先から求められるのは、多くの場合Type 2です。設計だけでなく、運用が続いていたかを見るためです。観察期間は3か月から12か月程度で設定されることが多く、初回は短く始めて次回から期間を延ばすやり方もよく採られます。ここは監査人と相談して決める部分になります。
期間の考え方で気をつけたいのが、報告書の「有効期限」です。認証のように何年間有効という形ではなく、報告書が対象とした期間が過ぎれば、次の期間の報告書が必要になります。実務では毎年更新していく前提で、証跡を残す仕組みを日常業務に組み込んでおくのが現実的です。
五つの規準——どこまでを範囲に含めるか
SOC 2の検証は、トラストサービス規準と呼ばれる観点に沿って行われます。セキュリティは基本として含み、そのほかは提供するサービスの性格に応じて選ぶ形です*2。
| 規準 | 見られる内容 | 含める判断 |
|---|---|---|
| セキュリティ | 不正なアクセスからの保護、権限の管理、監視と対応 | 基本として含める |
| 可用性 | 合意した水準でサービスを使える状態の維持、復旧の備え | 稼働率を約束している場合は含めたい |
| 処理の完全性 | 処理が正確・網羅的・適時に行われること | 計算や集計が価値の中心なら含める |
| 機密性 | 機密として扱う情報の保護と、不要になった際の廃棄 | 顧客の非公開情報を預かるなら含める |
| プライバシー | 個人情報の取得・利用・保存・廃棄の各段面の取り扱い | 個人データが中心なら検討する |
範囲を広げるほど、整えるべき統制も証跡も増えます。初回から五つすべてを含める必要はなく、取引先が実際に気にしている点から順に含めるのが現実的でしょう。逆に、稼働率を契約で約束しているのに可用性を範囲外にしていると、報告書を読んだ相手に物足りなさが残ります。
ISMS・ISMAPとの違いと使い分け
国内でセキュリティ体制を示す手段としては、ISMS（ISO/IEC 27001）の認証が広く使われています。政府調達に関わるならISMAPの登録も選択肢に入ります。SOC 2はこれらと排他ではなく、相手が求める形に合わせて使い分けるものです。
- ISMS（ISO/IEC 27001）：マネジメントシステムの認証。継続的な改善の仕組みがあることを示す。詳しくはISMS認証取得の進め方
- SOC 2：統制の運用状況について監査人が意見を述べる報告書。取引先が中身を読んで判断する
- ISMAP：政府情報システムの調達で参照される登録制度。詳しくはISMAPとは
三つを別々に整えると負担が重くなるため、共通する土台を先に作るのが定石です。資産の一覧、リスク評価、権限管理、変更管理、ログの保全、インシデント対応、委託先管理——このあたりはどの枠組みでも問われます。土台を一度作れば、あとは枠組みごとの様式に合わせて示し方を変えるだけになります。
すでにISMSを運用している企業なら、SOC 2の準備は「証跡の粒度を上げる作業」になることが多いはずです。方針や手順は揃っているものの、日々の運用の記録が個人の判断に委ねられている、という状態がよく見られます。ここを仕組みに落とすのが山場になります。
取得までの流れ——期間と体制のめやす
初回のType 2報告書を出すまでの流れは、五段階で捉えると見通しが立ちます。
第一に、範囲の決定です。どのサービス、どのシステム、どの拠点を対象にするか。ここを広く取りすぎると準備が終わりません。取引先が気にしているサービスに絞って始めるのが定石です。
第二に、現状分析です。規準に対して、いま何が足りないのかを洗い出します。多くの場合、方針はあるが記録がない、あるいは記録はあるが定期的な確認が行われていない、という不足が見つかります。
第三に、是正と整備です。手順書を整え、運用に乗せます。ここで重要なのは、人手でこなす前提の手順を増やしすぎないこと。棚卸しや権限レビューを手作業に頼ると、観察期間の途中で回らなくなります。
第四に、観察期間です。整えた統制を一定期間まわし、証跡を残します。3か月から始める例も多く、期間中に運用が崩れると例外事項として報告書に載ります。
第五に、監査と報告書の発行です。監査人が証跡を検証し、意見を付した報告書を発行します。初回は準備から発行まで、半年から1年程度を見込む企業が多いところです。費用は範囲と規模によって幅があるため、複数の監査人に見積りを取って比べるのが確実でしょう。
開発・運用側で問われる統制と、委託の実務
報告書のために新しいことを始めるというより、日常の運用が説明できる状態になっているかが問われます。開発・運用の現場で整えておきたいのは次の点です。
- アクセス管理：入社・異動・退職に連動した権限の付与と剥奪、定期的な棚卸し。アイデンティティ管理（IGA）の仕組みがあると証跡が揃いやすくなります
- 特権の扱い：本番環境への管理者アクセスを常時与えず、必要なときだけ期限つきで付与する。特権ID管理の導入が効きます
- 変更管理：レビューと承認を経て本番へ反映される流れが、記録として残ること
- 監視とログ：誰が何をしたかを追える監査ログの保全と、改ざんされない置き場所
- インシデント対応：検知から報告、復旧、振り返りまでの手順と、実施した記録
- 委託先管理：自社が使うクラウドやSaaSの評価と、契約における役割分担の明確化
これらは自動化と相性がよい領域です。権限の棚卸しをスプレッドシートで回している状態から、認証基盤の情報をもとに自動で一覧を出せる状態に変えるだけで、観察期間の負担は大きく下がります。ログの保全も、書き込み後に変更できない置き場所へ集約しておけば、証跡としての説明が容易になります。
外部に委託する場合は、「制度の解釈」と「仕組みの実装」を切り分けて依頼するのが得策です。規準の当てはめや報告書の書き方は監査人や専門家に確かめ、権限管理やログ集約、承認フローの実装は開発の委託先に任せる。この分担が明確だと、判断の責任があいまいになりません。
まとめ：SOC2対応で押さえる3つの視点
SOC 2は、統制の状況について監査人が意見を述べる保証報告書であり、認証とは性格が異なります。押さえたい視点は三つです。第一に、成果物は報告書であり、範囲と期間、例外事項まで読まれるため、「どのサービスのどの期間か」を示せる形にしておく必要があること。第二に、取引先が求めるのは多くの場合Type 2で、観察期間を通じて統制が機能していた証跡が問われるため、記録が自然に残る仕組みづくりが本質になること。第三に、ISMSやISMAPと共通する土台（資産の一覧・権限管理・変更管理・ログ・インシデント対応・委託先管理）を先に整えれば、枠組みごとの示し方を変えるだけで済むことです。まずは取引先が気にしている範囲に絞り、権限の棚卸しとログの保全を仕組みに落とすところから始めてみてください。
よくある質問
SOC2は認証ですか。ロゴを掲げられますか。
認証ではなく、監査人が意見を述べる保証報告書です。したがって「認証マーク」のような形での表示は前提になっていません。広く公開したい場合は、要約版にあたるSOC 3を用いる形になります。個別の商談では、範囲と期間を明示したうえで報告書を開示する使い方が一般的です。
Type1から始めても意味はありますか。
意味はあります。Type1は一時点の設計を見るもので、統制が整ったことを早めに示せます。ただし取引先が求めるのは多くの場合Type2であり、Type1だけで代替できるとは限りません。Type1で設計を固め、続けて観察期間に入ってType2へ進む段取りが現実的です。
ISMSを取得済みなら、SOC2は不要ですか。
相手が何を求めるかで決まります。ISMSはマネジメントシステムの認証、SOC2は統制の運用状況についての報告書で、示せる内容が異なります。海外の取引先や大手のSaaS事業者からはSOC2を求められる場面が多く、両方を求められることもあります。共通する土台を整えておけば、どちらにも対応しやすくなります。
準備期間と費用はどれくらい見ておけばよいですか。
初回は準備開始から報告書の発行まで、半年から1年程度を見込む企業が多いところです。観察期間を3か月にするか12か月にするかで大きく変わります。費用は対象範囲や規模、監査人によって幅があるため、複数の監査人から見積りを取って比べるのが確実です。社内の工数も相応にかかる点を織り込んでおきましょう。
開発側では、まず何を整えればよいですか。
権限管理とログの保全からです。入社・異動・退職に連動した権限の付与と剥奪、定期的な棚卸し、本番環境への特権アクセスを期限つきにする仕組み。そして、誰が何をしたかを追えるログを改ざんされない場所に集約すること。この二つが整うと、観察期間の負担が目に見えて軽くなります。
監査対応を見込んだシステム設計・運用のご相談はLASSICへ
元請（プライムベンダー）として、権限管理・変更管理・ログ集約・棚卸しの自動化まで、証跡が自然に残る仕組みづくりをご提案します。まずはお気軽にご相談ください。
出典
- *1 参考：AICPA & CIMA「System and Organization Controls (SOC) Suite of Services」（https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services）。SOC 1・SOC 2・SOC 3の位置づけと、報告書としての性格の参考として（2026年8月確認）
- *2 参考：AICPA & CIMA「SOC 2® — SOC for Service Organizations: Trust Services Criteria」（https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2-and-soc-3）。トラストサービス規準の構成とType 1・Type 2の違いの参考として（2026年8月確認）
