SOC2とは？5基準とType1・Type2の違いをSaaS開発側の証跡目線で解説

SOC2は、クラウドサービスやSaaSを提供する事業者の内部統制について、外部の会計士が検証した結果を報告書にまとめる制度です。取引先から「SOC2レポートを出してほしい」と言われたものの、何を用意すればよいのか、ISMS認証とどう違うのかがつかめないまま止まっている開発現場は少なくありません。この記事では、トラストサービス規準の5カテゴリと共通基準の構造、Type1とType2の違い、SOC1・SOC3との使い分けを一次情報にあたって整理します。あわせて、日本国内でSOC2に相当する報告書を発行する根拠となる保証業務実務指針3850との関係と、開発側が実際に用意することになる証跡までを扱います。

まとめ｜SOC2の要否と着手の順序をSaaS提供側の判断軸で先に示す

SOC2は認証ではなく、会計士が実施する保証業務の結果として発行される報告書です。合格・不合格という形の判定は出ず、統制の記述と検証手続、検出された例外事項が文章として残ります。したがって「取れば安心」ではなく「何をどこまで見せられる状態にしたか」が問われる仕組みだと理解するところから始まります。

判断の軸ははっきりしています。海外企業や外資系金融を顧客に持ち、購買審査でレポートの提出を求められるならSOC2、国内の政府調達を狙うならISMAP、社内の管理体制そのものを整えたいならISO27001というのが実務上の住み分けです。目的が「取引を通すこと」なら、求めてくる相手がどの証明を受け付けるかを先に確認するのが最短になります。

着手の順序は、対象範囲の確定、統制の記述、証跡が自動で残る仕組みの整備、そしてType1で整備状況を示し、期間を置いてType2に進む流れが標準です。開発側にとって負担が大きいのはType2で、アクセス権の棚卸しや変更管理の承認記録を、観察期間を通じて欠落なく残せるかどうかが結果を左右します。

SOC2の定義とAICPAが定める保証報告書としての位置づけを整理する

まず、誰が何のために定めた仕組みかを押さえます。名称の似た報告書が複数あるため、目的と読み手で区別すると混乱が減ります。

SOC2は誰が何を証明する報告書か・監査ではなく保証業務である理由

SOCはSystem and Organization Controlsの略で、米国公認会計士協会（AICPA）が定めた、受託業務を担う組織の統制を第三者が検証して報告するための枠組みです。AICPAが公開するSOC 2の解説では、セキュリティ、可用性、処理のインテグリティ、機密保持、プライバシーに関する統制を対象とすると示されています。

ここで押さえたいのは、SOC2が「認証」ではないという点です。ISO27001のように審査機関が規格適合を認定して登録証を交付する仕組みとは異なり、SOC2では会計士が統制の記述と運用を検証し、意見を付した報告書を発行します。読み手は顧客企業の購買部門やセキュリティ担当であり、報告書を読んで自社のリスクを評価します。

報告書には、対象システムの記述、経営者の主張、会計士の意見、統制ごとの検証手続と結果が含まれます。分量は数十ページに及ぶことが一般的で、公開資料ではなく秘密保持契約のもとで提供されるのが通例です。

SOC1・SOC3との棲み分けと報告書の配布先で決まる使い分け

SOCには目的の異なる報告書が並んでいます。SOC1は委託元の財務報告に関わる内部統制を対象とし、読み手は委託元の監査人です。給与計算やデータセンター運用のように、委託元の決算数値に影響する業務が典型になります。詳しくはSOC1レポートの定義と位置づけを整理した記事で扱っています。

SOC2は財務報告以外、つまり情報セキュリティや可用性を対象とし、読み手は顧客企業です。SOC3は同じ規準に基づきながら、詳細な統制記述や検証結果を省いた要約版で、Webサイトなどに一般公開できる点が違います。

営業資料に載せたいという理由でSOC3だけを取得しても、購買審査で詳細を求められれば結局SOC2が必要になります。順序としてはSOC2を先に取得し、その結果をもとにSOC3を発行する流れが素直です。

Trust Services Criteriaの5カテゴリと共通基準の構造を読み解く

SOC2で何を検証するかは、トラストサービス規準（Trust Services Criteria）という判断規準で決まります。5つのカテゴリのうちどれを対象にするかを、事業者側が選ぶ設計です。

5カテゴリの内容とセキュリティ以外の基準を追加する際の判断条件

現行の判断規準は2017 Trust Services Criteria（Points of Focusは2022年改訂版）です。5カテゴリの内容は次のとおりで、セキュリティは共通基準として全報告書で対象になり、残る4つは任意で追加します。

初回はセキュリティのみ、つまり共通基準だけを対象にする事業者が多数を占めます。カテゴリを増やすと統制の数と証跡の量がそのまま増え、検証費用と準備期間に跳ね返るためです。可用性を足すなら、稼働率の測定方法と障害時の復旧手順を数値で示せる状態が前提になります。

共通基準CC1からCC9がCOSOの内部統制フレームワークに紐づく構造

セキュリティに対応する共通基準は、CC1からCC9の9群で構成されます。このうちCC1からCC5は、COSO内部統制の基本的要素（統制環境、コミュニケーションと情報、リスク評価、モニタリング活動、統制活動）に対応しており、残るCC6からCC9が情報システム固有の領域を扱います。

報告書には判断規準とは別に、対象システムをどう記述するかを定めた規準があります。2018 SOC 2 Description Criteria（実装ガイダンスは2022年改訂）がそれにあたり、システムの境界、構成要素、対象期間中の変更などを漏れなく書くことが要件です。統制の中身より先に、この記述の粒度でつまずく事業者が目立ちます。

Type1とType2の違いは統制の整備と運用のどちらを見るかにある

SOC2の報告書は、検証の深さでType1とType2に分かれます。同じ統制を対象にしても、何を確かめるかが変わるため、準備の重さも大きく違います。

Type1が示す一時点の整備状況と報告書を利用する場面の見極め

Type1は、特定の基準日において統制が適切に設計され、実装されていることを検証した報告書です。会計士が確かめるのは「その日に仕組みが存在し、記述どおりに整備されているか」であり、期間を通じて機能していたかまでは問いません。

準備期間が短く済むため、初めて取り組む事業者が着手点として選ぶ場面が多くあります。取引先から提出を求められて時間がない場合に、まずType1を出し、次の期でType2に進むという段取りは実務でよく採られます。

ただしType1だけで審査を通過できるとは限りません。購買側がType2を明示的に求めることも珍しくないため、提出前に相手の要求水準を確認しておくと、二度手間を避けられます。

Type2の観察期間と証跡不足によって例外事項が記載される具体的な場面

Type2は、一定の観察期間にわたって統制が継続して運用されていたかを検証します。AICPAの規準は期間の長さを一律には定めておらず、実務上は3か月から12か月の範囲で設定し、初回は3か月から6か月、以降は12か月とする例が多く見られます。

ここで問われるのは記録の連続性です。会計士は期間中のサンプルを抽出し、その一件ごとに証跡を確認します。たとえば変更管理なら、期間中のリリースから任意の数件を選び、承認記録とテスト結果が残っているかが確認対象です。一件でも承認前にリリースされた記録が出れば、例外事項として報告書に記載されます。

例外事項が出ても報告書が無効になるわけではありませんが、読み手はその内容を評価します。したがってType2に進む判断は、「証跡が人手の運用に依存していないか」を確かめてからにするのが安全です。担当者が思い出して後から書いた記録は、日付の整合で見抜かれます。

日本でSOC2を取得する場合の保証業務実務指針3850と3402の関係

国内の事業者が日本の監査法人に依頼する場合、根拠となる実務指針は日本公認会計士協会が定めています。この点に触れている解説記事は多くないため、依頼前に押さえておくと会話が噛み合います。

保証業務実務指針3850が国内のTrust保証報告書を規律する

情報セキュリティ等に関する受託業務のTrustに係る保証報告書は、2021年4月14日に公表された保証業務実務指針3850が規律します。同時にQ&Aとして、IT委員会研究報告第55号が公表されました。この公表に伴い、IT委員会実務指針第2号および第5号、研究報告第45号は廃止されています。

財務報告目的の受託業務は別系統で、保証業務実務指針3402（2019年8月1日）が担います。かつての監査・保証実務委員会実務指針第86号や、Trust領域を扱っていたIT委員会実務指針第7号は、いずれも廃止されて現行の指針に引き継がれました。古い記事や社内資料に第86号や第7号の名前が残っていたら、参照先を差し替える段階にあります。

AICPA原文の適用が求められる範囲と参考翻訳を利用する際の位置づけ

3850は2022年10月13日に改正が承認されました。この改正で明確化されたのが、海外団体が公表している特定の規準を用いる場合、協会が示す参考翻訳ではなく海外団体の原文を適用する必要があるという点です。

実務への影響は具体的です。トラストサービス規準に基づく報告書を出すなら、拠り所はAICPAが公開する英語の原文になります。社内で統制を設計する際に日本語訳だけを見て要件を解釈すると、原文の語義との差が後工程で表面化することがあります。規準の条文レベルで議論する場面では、原文を並べて確認する運用にしておくと安全です。

ISMS認証やISMAPとの違いとSOC2を選ぶべき場面の判断基準

ここからは、どれを取るべきかという判断に踏み込みます。並べて比較すると、証明の性質そのものが違うことが見えてきます。

ISO27001は仕組みの認証・SOC2は統制の記述と検証結果

ISO27001は情報セキュリティマネジメントシステムの規格で、審査機関が規格への適合を認定し、登録証が交付されます。判定は適合か不適合かで示され、第三者に見せるのは登録証と適用範囲です。規格と管理策の全体像はISO27001の全体像と2022年版の管理策を整理した記事にまとめています。

対してSOC2は、統制の中身とその検証結果を文章で開示する報告書です。相手は登録証の有無ではなく、記述された統制が自社のリスクに見合うかを読んで判断します。つまりISO27001が「体制があること」の証明であるのに対し、SOC2は「何をどう統制しているか」の開示だと捉えると、使い分けの理由がつかめます。

両者は排他ではありません。ISO27001を先に取得していれば、方針や内部監査の記録が共通基準のCC1からCC5に流用でき、SOC2の準備負担は目に見えて軽くなります。逆にSOC2から始めた場合、CC6以降の技術統制は整うものの、組織的な文書が手薄になりがちです。

国内調達ならISMAP・海外SaaS取引ならSOC2という判断

判断は、報告書を求めてくる相手で決めます。政府機関へのクラウドサービス提供を狙うなら、登録が事実上の入場条件になる制度が国内に用意されています。制度の仕組みと費用感はISMAPのクラウドサービスリストと管理基準を解説した記事で扱いました。

一方、海外企業や外資系の顧客と取引する、あるいは自社がSaaSとして北米市場に出るなら、購買審査で提出を求められるのはSOC2レポートです。ここでISO27001の登録証を出しても、相手の審査プロセスに載らないことがあります。

採用を見送るべき場面も明確です。顧客が国内の中小企業に限られ、SOC2を求められた実績がないのであれば、初年度から数百万円規模の費用と社内工数を投じる合理性は乏しくなります。その場合はISO27001で体制を固め、SOC2を求める商談が出てきた時点でType1から着手する順序が現実的です。逆に、レポート提出が受注条件として提示されているなら、費用は営業経費として扱い、観察期間から逆算して着手時期を決めます。

SaaS開発側が用意する証跡と統制設計を実装へ落とし込む手順

ここが開発チームにとっての本題です。共通基準の条文を読んでも実装は決まらないため、日々の開発運用のどの仕組みが証跡を生むのかに翻訳して考えます。

共通基準の各群を開発運用のどの仕組みに割り当てるかを決める判断軸

CC6からCC8は、既存の開発基盤にそのまま対応づけられます。CC6の論理的アクセスはIDプロバイダと権限管理、CC7のシステム運用は監視基盤と脆弱性管理、CC8の変更管理はプルリクエストのレビューとCI/CDの記録が、それぞれ証跡の供給源になります。

割り当てで失敗しやすいのは、証跡を人が集める設計にしてしまう場合です。四半期ごとのアクセス権棚卸しを表計算で運用すると、期間中の一回でも抜けた瞬間に例外事項の候補になります。IDプロバイダのグループ変更ログをそのまま証跡とする設計に寄せておけば、観察期間の長さに関わらず記録は自動で積み上がります。

CC7に含まれる脆弱性管理は、定期的な検査の記録が求められる領域です。自社に検査の体制がなければ、脆弱性診断・セキュリティ診断のような外部の診断を定期実施し、その報告書と是正の記録を証跡として保管する形が取りやすくなります。

Type2で通らない証跡の典型と統制設計の段階で潰しておくべき箇所

観察期間の検証で引っかかる箇所には、傾向があります。開発側で先回りして潰せるものが多いため、着手前に次の点を点検しておくと、後戻りが減ります。

1. 退職者アカウントの削除が、人事の申請ベースで数日遅れている。
2. 本番環境への緊急変更が、事後承認のまま記録に残っていない。
3. 特権アカウントを開発者が共用し、誰の操作か特定できない。
4. ログの保存期間が観察期間より短く、期首の記録が消えている。
5. 委託先の再委託が把握されておらず、CC9で説明できない。

いずれも、仕組みで解けます。退職連携は人事システムからIDプロバイダへの自動反映に寄せ、緊急変更は事後承認のワークフローを定義して記録が必ず残るようにします。ログの保存期間は、観察期間に会計士の検証時期を足した長さを確保しておくのが目安です。

準備の進め方としては、対象範囲を決め、共通基準の群ごとに既存の仕組みを棚卸しし、証跡が自動で残らない箇所だけを改修する順序が効率的です。すべての統制を新規に作り直す必要はなく、実際に手を入れるのはアクセス管理と変更管理の記録まわりに集中します。外部の支援を使う範囲も、規準の解釈と報告書の記述部分に絞れば、費用は抑えられます。

よくある質問

SOC2の取得を検討する事業者から寄せられることの多い質問に、要点を絞って答えます。

SOC2とSOC2 Type2は別の制度ですか？

別の制度ではありません。SOC2という報告書の種類の中に、検証の深さによってType1とType2という区分があります。Type1は基準日時点の整備状況、Type2は観察期間を通じた運用状況までを検証したものです。取引先が「SOC2」とだけ伝えてきた場合、実務ではType2を想定していることが多いため、どちらを求めているかを確認してから着手する形が安全です。

SOC2に有効期限はありますか？

登録証のような有効期限はありませんが、報告書には対象となる基準日または観察期間が明記されます。読み手は期間の新しさで判断するため、実務上は1年ごとに更新し、期間が途切れないように継続して発行する運用が一般的です。前回の期間終了から次の期間開始までに空白があると、その間の統制を説明できない状態になります。

ISO27001を取得済みならSOC2の準備は軽くなりますか？

軽くなります。共通基準のCC1からCC5は、方針、職務分掌、リスクアセスメント、内部監査といった組織的な統制を扱うため、ISO27001の運用記録をそのまま証跡に回せる部分が多くあります。ただし対象範囲の切り方や記述の粒度は制度ごとに異なり、CC6以降の技術統制は個別に整理が必要です。準備の重複が省けるという意味であり、そのまま流用できるわけではありません。

日本の監査法人でもSOC2レポートは発行できますか？

発行できます。国内では保証業務実務指針3850が根拠となり、日本の監査法人が保証報告書を発行します。ただし2022年10月の改正で、海外団体の規準を用いる場合は参考翻訳ではなく原文を適用する必要があることが明確化されました。海外の顧客に提出する前提であれば、報告書の言語や記載形式について、依頼先と事前に擦り合わせておくと後の手戻りを防げます。

準備期間と費用はどのくらい見ておくべきですか？

対象範囲とカテゴリの数で大きく変わります。セキュリティのみを対象にした初回のType1でも、範囲の確定と記述の作成に数か月を要する例が多く、Type2はそこに観察期間が加わります。費用は保証業務の報酬に加え、規準解釈の支援や不足統制の改修コストが積み上がる構造です。まず対象システムの境界を狭く切り、証跡が自動で残る領域から固めることが、期間と費用の両方を抑える近道になります。

関連記事

• 財務報告に関連する内部統制をサードパーティが証明するSOC1レポートの基本的な定義と位置づけ：財務報告目的の受託業務を対象とするSOC1について、SOC2との違いを含めて整理しています。
• ISO27001とは？ISMS認証の全体像・2022年版の管理策と取得手順を実務目線で解説：認証としての性質と管理策の構成を押さえると、SOC2との使い分けが判断しやすくなります。
• ISMAPとは？クラウドサービスリスト・管理基準・費用を2026年時点で解説：国内の政府調達を狙う場合に必要となる制度を、費用感まで含めて解説した記事です。