SOC2 Type2監査ガイド｜費用相場・期間・準備手順・監査法人選び【SaaS向け2026】

結論から先に。 SOC2 Type2は「一定期間（一般に6〜12ヶ月）にわたって、セキュリティ統制が設計どおりに運用され続けていたこと」を、独立した米国公認会計士（CPA）事務所が第三者として検証した報告書です。SaaS事業者にとっては、認証バッジそのものよりも「エンタープライズ顧客・海外顧客の購買審査を通過するための入場券」としての意味が大きく、これがないと商談が止まる、という理由で取得が始まるケースがほとんどです。

要点だけ先に押さえておきます。

• Type1は「ある時点で統制が正しく設計されているか」、Type2は「その統制が期間を通じて実際に効いていたか」を見る。 顧客が最終的に求めるのはType2です。
• SOC2は「認証（certification）」ではなく「監査報告書（attestation report）」。 ISMS（ISO/IEC 27001）のような合否のバッジではなく、監査人の意見と統制のテスト結果が数十ページにわたって書かれた文書が成果物です。ここを取り違えると、社内説明も顧客提出も噛み合いません。
• 評価軸はTrust Services Criteria（TSC）という5領域。 Security（セキュリティ）だけが必須で、Availability・Processing Integrity・Confidentiality・Privacyは自社のサービス特性に応じて任意で足します。
• 費用も期間も「スコープ次第」で大きく動く。 相場を一律の金額で語るのは危険です。本記事では金額を断定せず、何が費用を動かすかという分解の仕方を示します。
• 一番の失敗は「監査ウィンドウを走らせ始めてから統制の穴に気づく」こと。 Type2は過去の運用実績を後から作れないため、準備の順番を間違えると半年〜1年を無駄にします。

この記事は、監査法人の営業資料でも、GRCツールベンダーのポジショントークでもありません。SaaSを提供する事業者が「自社で取りに行くべきか」「どの順で準備し、どこで外部の力を借りるか」を判断するための、発注者側の視点でまとめた実務ガイドです。定義はAICPA（米国公認会計士協会）のフレームワークに沿って確認し、費用や期間の実例は二次情報である旨を明記して扱います。

この記事を読むべき人

• エンタープライズ顧客や海外顧客から「SOC2レポートはありますか」と聞かれ、商談が止まった、あるいは止まりそうなSaaS事業者の経営者・事業責任者
• セキュリティ質問票（Security Questionnaire）への回答対応に毎回工数を奪われていて、恒久的な解決策を探している情シス・コーポレート担当
• SOC2の見積もりを複数取ったが、金額のばらつきが大きく、何が違うのか判断できない決裁者
• ISMS（ISO 27001）は取得済みで、SOC2との違いや流用可否を知りたい担当者
• 「そろそろ取ったほうがいいらしい」という空気だけで、投資判断の根拠を言語化できていない経営層

社内にセキュリティ専任がいない、情シスが一人または兼任、という体制でも取得は可能です。ただし「誰が・何を・どの順で」進めるかを設計しないまま監査法人やツールに丸投げすると、費用が膨らみ、期間も延びます。その勘所を後半でチェックリスト化しました。

SOC2とは何か——SOC1/SOC2/SOC3の位置づけ

SOC（System and Organization Controls）は、AICPAが定めた「サービス組織の内部統制に関する保証報告」の枠組みです。他社に業務やシステムを預けている利用者側が、その委託先のリスクを評価・説明できるようにするための報告書、という位置づけです。SOCには目的の異なる3種類があります。

SaaS事業者が求められるのは基本的にSOC2です。SOC3はSOC2をもとにした要約でWebサイトに公開できますが、統制のテスト結果という肝心な中身が省かれるため、購買審査の証跡としてはSOC2レポート本体（詳細版）の提出を求められるのが通常です。

ここで日本企業がよく混同するのが、SOC2とISMS（ISO/IEC 27001）の違いです。両者はカバー範囲が重なりますが、性質が異なります。

• ISMSは「認証」。 認証機関が基準への適合を審査し、合否でバッジ（認証書）が出る、パス／フェイル型です。日本国内では知名度が高く、公共・国内取引の要件になりやすい。
• SOC2は「保証報告（attestation）」。 CPA事務所が統制を検証し、その意見と個々の統制のテスト結果を記述した報告書が成果物です。バッジではなく「読ませる文書」であり、北米SaaS市場では事実上の標準になっています。

つまり、日本国内取引が中心ならISMS、北米・グローバルのエンタープライズSaaS取引を狙うならSOC2、という使い分けが実務の目安です。ISMSを既に持っている場合、アクセス管理・変更管理・インシデント対応などの統制やポリシー文書はSOC2にかなり流用でき、ゼロから作るより準備負荷は下がります（ただし証跡の粒度や運用の実績要件はSOC2独自なので「そのまま通る」わけではありません）。

Type1とType2の違い——なぜ顧客はType2を求めるのか

SOC2にはType1とType2があり、この違いが取得計画の骨格を決めます。

Type1は「ルールと仕組みを整えました」という設計の証明で、比較的短期に到達できます。一方Type2は「そのルールが対象期間中、本当に守られ続けていたか」を、証跡（Evidence）に基づいて監査人がテストします。ここが最大のポイントで、Type2の運用期間は後から作れません。 例えば「四半期ごとにアクセス権をレビューする」という統制なら、監査対象期間中に実際にレビューを実施し、その記録が残っていることが必要です。準備が整わないうちに監査ウィンドウ（観察期間）を走らせてしまうと、証跡が空白のまま期間が過ぎ、指摘（例外事項）が並ぶ報告書になってしまいます。

顧客がType2を求めるのは、「設計だけなら見せかけでも作れるが、半年〜1年運用し続けた実績は誤魔化しが効かない」からです。だからこそ、初回はType1で早く一枚看板を作り、翌サイクルでType2に移行する、という段階戦略が現実的な選択肢になります。ただし顧客側の要求が最初からType2で固い場合は、Type1を挟まずいきなりType2の観察期間に入る判断もあり得ます。ここは商談相手の要求水準から逆算して決めます。

5つのTrust Services Criteria（TSC）と選び方

SOC2の評価軸は、AICPAが定めるTrust Services Criteria（TSC）という5つの領域です。このうちSecurityは全社共通の土台（Common Criteria＝共通基準とも呼ばれます）で、SOC2を名乗る以上は必須。残り4つはサービスの性質に応じて任意で追加します。

選び方の実務的な目安は「顧客が求める最小限から始め、後から足す」です。TSCを増やすほど統制項目・証跡・監査工数が増え、費用と期間に直結します。よくあるのは、意気込んで5基準すべてを対象にし、準備が終わらず頓挫するパターン。まずはSecurity単独、SLAを掲げているならSecurity＋Availability、というのが多くのSaaSの現実的なスタートラインです。Privacyは要件が重く、個人情報保護法・GDPR等との整理も絡むため、本当に顧客要求があるかを確認してから足すのが安全です。

※各基準の選択比率をパーセンテージで断言する情報が国内外に流通していますが、出典が曖昧なものが多いため、本記事では割合の数値は示しません。自社が足すべき基準は「市場平均」ではなく「目の前の顧客の要求」から決めてください。

取得プロセスと期間——監査ウィンドウとブリッジレター

Type2取得の標準的な流れは次のとおりです。着手からType2報告書の入手まで、準備の巧拙で幅は出ますが、おおむね9〜15ヶ月を見込むのが現実的です（運用観察期間そのものに6〜12ヶ月かかるため、ここは短縮に限界があります）。

ここで発注者が理解しておくべき2つの実務概念があります。

監査ウィンドウ（Observation Period）：Type2が「期間」を見る以上、いつからいつまでを観察対象にするかを決めて宣言する必要があります。この期間中の証跡がそのまま評価対象になるため、統制が回り始めてから、余裕をもって開始日を設定するのが鉄則です。初回は3〜6ヶ月の短めの窓で早く一本目を出し、翌サイクルで12ヶ月に伸ばす、という運び方もよく採られます。

ブリッジレター（Bridge Letter / Gap Letter）：SOC2報告書には対象期間の終了日があります。顧客が審査するのはたいてい報告書発行から数ヶ月後で、「報告書の期間終了後から今日まで、重大な統制変更はありません」と会社が表明する橋渡しの書面がブリッジレターです。これがないと、顧客側で「報告書が古い」と判断され、審査が止まることがあります。年次で更新し続ける前提の制度である、という点を最初から織り込んでおきましょう。

費用の考え方——金額の断定ではなく「何が費用を動かすか」

SOC2の費用は「いくら」と一律に言えるものではありません。TSCの数、システムの複雑さ、対象拠点、GRCツールの有無、監査法人の規模、ペネトレーションテストの範囲で大きく変動します。ここでは金額を断定せず、費用を構成する要素を分解します。

参考として、GRC自動化ツールを使って費用を大きく抑えた国内SaaSの公表事例があります。ある企業は初年度をVanta利用料・監査法人報酬・ペネトレーションテストを合わせて概ね数百万円規模（従来型の見積もりより大幅に圧縮）で取得したと自社ブログで公表しています（出典：企業自身のnote記事＝二次情報。金額は同社の条件・時期に固有で、他社にそのまま当てはまるものではありません）。一方で、拠点や連携が多く、複数TSCを対象にすれば、費用は桁が変わります。「SOC2は◯◯万円」という単一の相場を鵜呑みにしないこと。 見積書を読む際は、上の分解表のどこにお金が乗っているかを一項目ずつ確認するのが、比較の唯一の正攻法です。

見積もりの読み方——複数社を横並びにする前に確認する4点

1. スコープ（対象システム・拠点・TSC）が同一条件か。 ここが揃っていない見積もりの金額を比べても意味がありません。まず自社側でスコープを固定し、同一条件でRFPを出します。
2. 監査法人報酬とコンサル報酬が分離されているか。 「一式」でまとまった見積もりは、後から追加費用が乗りやすい。工程ごとの内訳を要求します。
3. ペネトレーションテストが含まれるか／別か。 監査要件として必要な範囲と、営業的に足された範囲を切り分けます。
4. 翌年以降の継続費用（更新監査・ツール年額・ブリッジレター対応）が見えているか。 SOC2は取って終わりではなく、毎年回す制度です。初年度だけの金額で判断すると、二年目に予算が破綻します。

監査法人（CPA事務所）とGRCツールの選び方

監査法人（CPA事務所）の選定軸は、価格よりも実績と相性です。SOC2はライセンスを持つCPA事務所しか署名できません（ここがISMSの認証機関と違う点です）。見るべきは、（1）SaaS・クラウドの監査実績が豊富か、（2）自社が使うGRCツールと連携経験があるか、（3）英語だけでなく日本語でのコミュニケーションが取れるか（国内チームの実体験として、監査人との英語やり取りが負荷になったという声は少なくありません）、（4）例外事項が出たときの相談に乗ってくれるか、です。安さだけで選ぶと、証跡の解釈で揉めたり、報告書の記述が薄く顧客審査で追加質問が来たりします。

GRCツール（コンプライアンス自動化プラットフォーム） は、証跡収集の自動化で工数を大きく削減できるため、少人数体制ほど費用対効果が出やすい投資です。代表的な選択肢を整理します。

ツール選定の落とし穴は「ツールを入れれば取れる」という誤解です。GRCツールは証跡を集める配管であって、統制そのものを作ってはくれません。連携先（クラウド、ID基盤、コード管理、人事）が自社のスタックに合っているか、日本語対応と国内サポートの実体、契約は年単位か、を発注前に確認してください。ツールに合わせて業務を変えるのではなく、自社の運用を証跡化できるツールを選ぶ順番が正解です。

GXOが見る「発注前チェックリスト」

SOC2を外部に相談する前に、発注者側で以下を整理しておくと、見積もりのブレ・手戻り・ベンダー依存を大きく減らせます。これは監査法人やツールに聞かれる前に、自社で答えを持っておくべき項目です。

• なぜ取るのかを一文で言えるか（特定顧客の要求／市場全体の要求／将来の布石のどれか）。動機が曖昧だとスコープが膨らむ
• Type1から入るか、いきなりType2の観察期間に入るかを、顧客の要求水準から逆算して決めたか
• 対象TSCを「顧客要求の最小限」で仮置きしたか（全部盛りにしていないか）
• スコープ（対象プロダクト・環境・拠点）を1枚に固定したか
• 監査ウィンドウの開始日を、統制が回り始めた後に設定できる計画か
• 主要統制（MFA、最小権限、四半期アクセスレビュー、変更管理、ログ90日以上、インシデント対応手順、暗号化、バックアップ/DR、ベンダー管理、入退社処理）が「運用に落ちて」いるか、作っただけでないか
• 証跡（Evidence）を誰が・どの頻度で・どこに残すかの責任者を決めたか
• 社内オーナー（丸投げしない責任者）を1名置いたか
• 既存のISMS/ISO 27001の統制・文書で流用できるものを棚卸ししたか
• 初年度費用だけでなく、二年目以降の更新監査・ツール年額・ブリッジレター運用まで予算化したか

よくある失敗パターン

日本のSaaSがSOC2 Type2を取る意義——「商談要件化」への備え

日本のSaaS事業者にとって、SOC2の本質的な価値は「セキュリティが良くなること」そのものより、商談のスピードと勝率が上がることにあります。エンタープライズや外資系の購買プロセスでは、ベンダー選定時に長大なセキュリティ質問票への回答を求められます。SOC2レポートは、この質問票の多くを「レポートを参照してください」で置き換えられるため、営業サイクルの短縮と、審査落ちの回避に直結します。裏を返せば、SOC2がないことが受注の前提条件で弾かれる理由になる局面が、日本市場でも確実に増えています。

一方で、SOC2は目的ではなく手段です。監査を通すためだけに形式的な統制を作ると、運用が形骸化し、二年目の更新で崩れます。本来のゴールは「顧客に説明できるセキュリティ運用が、事業のスピードに合わせて回り続けること」。SOC2はそれを外部が保証してくれる仕組みにすぎません。だからこそ、取得の前に自社のセキュリティ・IT運用体制が今どのレベルにあるのかを把握することが、投資判断の出発点になります。自社の現在地を短時間で見立てたい場合は、自社のDX・IT体制の成熟度を可視化する無料診断で、まず「どこが弱く、次に何を整えるべきか」の当たりを付けるところから始めるのが手戻りが少ない進め方です。

統制の設計・実装や、監査で問われるログ・権限・インシデント対応の運用まで含めて体制を作り直す必要があるなら、セキュリティ体制の再構築（SIEM・権限・運用設計）の視点で全体像を描くと、監査対応が「点」の作業ではなく「線」の運用としてつながります。さらに、情シスが一人または兼任で「作った統制を回し続ける人がいない」という典型的な課題を抱えているなら、月次で運用を伴走するセキュリティ顧問（リテイナー）のように、証跡管理・棚卸し・脆弱性対応を継続運用に乗せる選択肢を早めに検討しておくと、Type2の「期間を通じて効き続ける」という要件に無理なく応えられます。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、情報収集を続けるより、早い段階で第三者に整理を相談したほうが、費用と期間の両方を節約できます。

• 顧客からSOC2を求められ、自社で取るべきか・どのType/TSCから始めるかの判断がつかない
• 複数の監査法人・コンサルから見積もりを取ったが、金額差の理由を説明できない
• GRCツールの営業を受けているが、自社スタックに本当に合うか、費用対効果があるか判断できない
• ISMSは持っているが、SOC2との重複・流用範囲を整理したい
• 統制は「作った」が運用に落ちておらず、監査ウィンドウを開始してよいか不安
• 社内稟議で「なぜ今、いくらかけて取るのか」を経営に説明する材料が要る

GXOは監査法人でもツールベンダーでもない立場から、現状の統制の棚卸し、スコープとType/TSCの設計、見積もりの妥当性検証、そして「作って終わり」にしないための運用設計まで、発注者側の目線で整理を支援します。特定のツールや監査法人を売るのではなく、自社条件に合った進め方を一緒に決めるところに価値を置いています。

FAQ

SOC2は「認証」ですか？取ると認証マークがもらえますか？

いいえ。SOC2はISMS（ISO 27001）のような合否の認証ではなく、CPA事務所が発行する「保証報告書（attestation report）」です。バッジではなく、監査人の意見と統制のテスト結果が記載された文書が成果物で、顧客にはNDAのうえで提出します。一般公開したい場合は要約版のSOC3を使います。

Type1を飛ばして、いきなりType2を取れますか？

取れます。顧客がType2を最初から要求している場合は、Type1を挟まず観察期間に入る判断もあります。ただしType2は運用実績を後から作れないため、統制が回り始めてから観察ウィンドウを設定する必要があります。まず統制を整え、短めの窓でType2を一本出し、翌サイクルで期間を伸ばす運びも一般的です。

取得にはどれくらいの期間がかかりますか？

Type2は運用観察期間（一般に6〜12ヶ月）が構造的に必要なため、着手から報告書入手まで概ね9〜15ヶ月が現実的な目安です。準備（レディネス評価・統制実装）の巧拙で前半は伸縮しますが、観察期間そのものは短縮に限界があります。

費用はいくらですか？

スコープ・TSCの数・システム複雑度・拠点・ツール・監査法人の規模で大きく変動するため、一律の相場を鵜呑みにしないでください。GRC自動化ツールで費用を数百万円規模に抑えた国内SaaSの公表事例もありますが（同社固有の条件による二次情報）、複数TSC・多拠点なら費用は桁が変わります。見積もりは工程ごとの内訳と、二年目以降の継続費用まで含めて比較してください。

ISMS（ISO 27001）を持っていれば、SOC2は簡単に取れますか？

統制やポリシー文書の多くは流用できるため、ゼロから始めるより準備負荷は下がります。ただしSOC2独自の証跡の粒度・運用実績要件があり、「そのまま通る」わけではありません。まず既存統制の棚卸しから始め、SOC2で追加・調整が必要な差分を洗い出すのが効率的です。

一度取れば、それで終わりですか？

いいえ。SOC2は年次で更新し続ける前提の制度です。報告書には対象期間があり、その後の期間はブリッジレターで橋渡ししますが、恒久的に済む書面ではありません。更新を止めると顧客審査で「レポートが古い」と判断され、商談が止まります。取得後に運用を回し続ける体制まで含めて設計してください。

参考にした一次・公式情報

• AICPA & CIMA — SOC 2® reporting（SOC制度の公式提供元）
• Microsoft Learn — SOC 2 Type 2 の解説（日本語・一次的な制度解説）
• Secureframe — 2025 Trust Services Criteria for SOC 2（5基準の定義解説）

上記は制度・定義の裏取りに用いた情報です。費用・期間の実例に触れた箇所は、各社が公表するブログ・note等の二次情報であり、その企業固有の条件・時期に依存する点を本文中に明記しています。制度・価格・仕様は変わり得るため、実際の投資判断の際は公開時点の公式情報とあわせて再確認してください。SOC2は「取ること」ではなく「顧客に説明できる運用が回り続けること」がゴールです。自社の現在地の見立てと、そこからの一手の設計に迷ったら、判断軸の整理から一緒に始めましょう。