新しいSaaSを導入しようとすると、稟議やセキュリティチェックシートで「ベンダーのSOC2レポートを確認すること」と求められる場面が増えてきました。ところが、いざ調べてみるとSOC2のほかにもISMS（ISO27001）、プライバシーマーク、ISMAPといった言葉が次々と出てきて、「結局どれがあれば安全なのか」「自社が使うサービスをどう見比べればいいのか」が分からなくなってしまう。そんな経験はないでしょうか。
社内に情報セキュリティの専任者がいない中で、増え続けるSaaSの「発注前チェック」を任される担当者にとって、複数の認証・基準が乱立する状況はとても判断しづらいものです。さらに厄介なのは、「SOC2を取得しているから大丈夫」と一度思い込んでしまうと、本当は確認すべき範囲や限界を見落としてしまうリスクがあることです。SOC2は強力な判断材料ですが、「持っていれば全部安心」という性質のものではありません。
この記事では、こうした混乱を解消するために、まずSOC2が「認証」ではなく「報告書（レポート）」であるという基本から整理します。その上で、SOC2が評価する5つの基準、Type1とType2の違い、ISMS・プライバシーマーク・ISMAPとの違いを発注者目線の比較表にまとめ、レポートの読み方とSOC2の限界、さらにSOC2の先に確認すべきチェックリストまでを解説します。
読み終えるころには、「このSaaSはここを確認済み」と社内で自信を持って説明できる、あなた自身の判断軸が手に入るはずです。SaaS選定を任された担当者の方は、ぜひ最後までご覧ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
SOC2とは何か｜認証ではなく「レポート」である理由
SaaSのセキュリティを評価する文脈で最初に押さえておきたいのが、SOC2が「認証」ではなく「報告書」だという点です。ここを誤解したままだと、後の判断がすべてずれてしまいます。まずはSOC2の正体から整理しましょう。
SOC2は誰が・何を・どう評価する仕組みか
SOC2（System and Organization Controls 2）は、米国公認会計士協会（AICPA）が定めた枠組みに基づいて、SaaSやクラウドサービスを提供する事業者の内部統制を、独立した第三者である監査人が評価し、その結果を報告書としてまとめたものです。
ここでいう「内部統制」とは、サービスを安全・適切に運営するための社内の仕組みやルール（アクセス権限の管理、データの取り扱い手順、障害対応の体制など）を指します。SOC2では、こうした仕組みが「きちんと設計されているか」「実際に運用されているか」を、監査人が証拠を確認しながらチェックします。
つまりSOC2を一言でいえば、「クラウドサービス事業者のセキュリティ等に関する社内体制を、会計監査の専門家が第三者の立場で審査し、その所見を文書にまとめた保証報告書」です。発注者である利用企業は、ベンダーが自己申告する「うちは安全です」という言葉ではなく、第三者が確認した客観的な記録をもとに信頼性を判断できる、というのがSOC2の価値の中心にあります。
「認証」ではなく「レポート（報告書）」であることの意味
ここが多くの発注担当者がつまずくポイントです。SOC2は「認証（合格・不合格を示すお墨付き）」ではありません。後ほど解説するISMSやプライバシーマークが「審査に通れば認証マークが付与される」仕組みであるのに対し、SOC2は「監査人の意見と発見事項が書かれたレポート」が成果物です。
この違いは実務上とても大切です。認証であれば「持っている／持っていない」の二択で判断できますが、SOC2の場合は「レポートを受け取って、その中身を読む」ところまでが確認の作業になります。レポートには、監査人がどの範囲を・どの期間にわたって評価し、その結果どんな所見（場合によっては見つかった不備）があったのかが記載されています。
そのため、「ベンダーがSOC2レポートを持っているらしい」という情報だけでは、確認したことにはなりません。あくまで中身を読み、評価された範囲・期間・所見を把握して初めて、発注者としての確認が完了します。この「中身を読む」という前提は、本記事を通じて繰り返し登場する重要な視点です。
なお、より正確には、SOC2はAICPAが公表する保証業務基準に基づく報告書であり、その評価基準は次に解説する「トラストサービス基準」として体系化されています（参考: SOC2レポートとは？評価基準やISMSとの違いを解説します（assured.jp））。
SOC2が評価する5つの基準（トラストサービス基準）とは
SOC2が「何を評価しているのか」を理解するには、評価の物差しである「トラストサービス基準」を知っておく必要があります。この基準を押さえると、「SOC2と一口に言っても、サービスによって評価された範囲が違う」ことが見えてきます。
5つのトラストサービス基準の概要
トラストサービス基準は、AICPAが定めた5つの観点（カテゴリ）で構成されています（参考: Trustサービスに関する規準（日本公認会計士協会））。それぞれの観点で何を評価するのかを、発注者目線で簡単に整理すると次のとおりです。
- セキュリティ（共通基準）: 不正アクセスや情報の改ざん・漏えいからシステムを守る仕組みが整っているか。アクセス制御や物理的・論理的な防御がここに含まれます。
- 可用性: サービスが約束された水準で利用できる状態に保たれているか。障害対応や冗長化、稼働監視などが評価対象です。
- 処理のインテグリティ（完全性）: システムの処理が、完全・正確・適時に、かつ承認された形で行われているか。データが正しく処理される仕組みを見ます。
- 機密保持: 機密として扱うべき情報が、適切に保護・管理されているか。秘密保持の取り決めや暗号化などが含まれます。
- プライバシー: 個人情報の収集・利用・保管・廃棄が、定めたポリシーに沿って適切に行われているか。
これら5つは、サービスの性質に応じて「どこまでを評価対象にするか」が変わります。
必須はセキュリティのみ｜発注者は「どの基準まで対象か」を確認する
ここで重要なのが、5つの基準のうちSOC2レポートで必須とされるのは「セキュリティ」だけだという点です。残りの可用性・処理のインテグリティ・機密保持・プライバシーは、サービス事業者が自らの判断で評価対象に含めるかどうかを決めます（参考: SOC2レポートとは？評価基準やISMSとの違いを解説します（assured.jp））。
これは発注者にとって見逃せないポイントです。たとえば、あるSaaSが「SOC2レポートを取得しています」と説明していても、評価対象が「セキュリティ」のみで、自社が最も気にしている「可用性（サービスが止まらないか）」や「プライバシー（個人情報の取り扱い）」は評価範囲に含まれていない、というケースがありえます。
そのため、SOC2の有無を確認するだけでなく、「そのレポートはどの基準まで対象としているか」を必ず確認しましょう。自社のSaaS利用用途と照らし合わせて、本当に気にすべき観点が評価されているかを見ることが、形だけのチェックに終わらせないための第一歩です。「どこまで保証されているか」を確認するこの視点は、のちほどの限界の話にもつながっていきます。
SOC2 Type1とType2の違い｜どちらを確認すべきか
SOC2レポートには「Type1」と「Type2」という2つの種類があります。ベンダーから「SOC2 Type2を取得済みです」と言われて意味が分からなかった、という方も多いのではないでしょうか。この違いは信頼性の差に直結するため、発注者として必ず押さえておきたいところです。
Type1は「時点評価」、Type2は「期間評価」
両者の違いは、評価が「ある一時点」を見るのか「一定期間」を見るのかにあります。
- Type1: ある特定の時点において、内部統制が適切に「設計・整備」されているかを評価したレポートです。いわば「ある一日のスナップショット」で、仕組みが正しく作られているかを確認します。
- Type2: 一定期間（一般的に半年〜1年程度）を通じて、内部統制が適切に整備され、かつ「有効に運用されている」かを評価したレポートです。仕組みが作られているだけでなく、その期間にわたって実際にきちんと回っていたかまでを確認します（参考: SOC2 Type1とType2の違いとは？（令和監査法人））。
たとえるなら、Type1は「防火設備が設計図どおりに設置されているか」を竣工時に点検したもの、Type2は「その防火設備が半年〜1年の間、実際に正しく作動し続けたか」を運用記録まで含めて確認したもの、という違いです。
発注者の判断｜Type2が望ましい理由とType1を見るときの注意点
継続的に安全な運用がされているかという裏付けを求めるなら、Type2のレポートを確認するのが望ましいといえます。一方で、Type1はあくまで時点評価であり、「その後も同じ水準で運用が続いている」ことまでは保証していない点に注意が必要です。発注者の実務における判断軸を表に整理します。
観点 | Type1 | Type2 |
|---|---|---|
評価する内容 | 内部統制の設計・整備状況 | 設計・整備に加え、一定期間の運用状況 |
評価の対象 | ある特定の時点 | 一定期間（半年〜1年程度が一般的） |
分かること | 仕組みが正しく作られているか | 仕組みが期間を通じて有効に機能していたか |
信頼性の度合い | 運用実績の裏付けはない | 運用実績まで含めて確認できる |
発注者の見方 | 導入初期や移行段階のサービスで見られる。時点評価にとどまる点に注意 | 継続的な運用の裏付けを確認したいときに優先 |
新しく立ち上がったサービスでは、まずType1を取得し、その後一定期間の運用を経てType2へ移行するという段階を踏むのが一般的です。そのため、Type1しかない＝即NGというわけではありませんが、「現時点では運用実績の評価まではされていない」という前提を理解した上で判断しましょう。
SOC2・ISMS・プライバシーマーク・ISMAPの違い【発注者向け比較表】
ここからが、本記事の核心です。SOC2・ISMS・プライバシーマーク・ISMAPという複数の基準が乱立して見えるのは、それぞれ「目的」と「形式」が異なるからです。「どれがあれば安全か」という発想ではなく、「何を確認したいときに、どれを見ればよいか」という発注者目線で整理すると、混乱はかなり解消されます。
4つの制度を「発注者が確認できること」で比較する
項目 | SOC2 | ISMS（ISO27001） | プライバシーマーク | ISMAP |
|---|---|---|---|---|
主な対象 | クラウド・SaaS事業者の内部統制 | 組織全体の情報セキュリティ管理体制 | 個人情報の取り扱い体制 | 政府調達向けクラウドサービスのセキュリティ |
形式 | 監査報告書（レポート） | 第三者認証 | 第三者認証 | 登録制度（クラウドサービスリストへの登録） |
何を保証するか | 内部統制が設計・運用されていることへの監査人の所見 | 情報セキュリティの管理の仕組みが規格に適合していること | 個人情報保護の体制が基準に適合していること | 政府が求めるセキュリティ要求を満たしていること |
発注者が確認できること | 評価範囲・期間・所見をレポート本文で具体的に確認できる | 認証の有無・適用範囲（認証登録証）を確認できる | 認証マークの有無を確認できる | クラウドサービスリストに登録されているかを確認できる |
典型シーン | 海外製・国内のSaaSのセキュリティ確認、特にBtoB | 取引先・発注先の情報セキュリティ体制の確認 | 個人情報を多く扱う事業者の確認 | 政府機関・官公庁向けのクラウド調達 |
補足として、ISMAPは政府調達時に登場する基準です。各省庁が新たにクラウドサービスを導入する際、ISMAPのクラウドサービスリストをもとに選定する仕組みになっており、民間企業同士の取引で必須になる場面は限定的です（参考: ISMAP概要（ISMAPポータル））。政府・官公庁との取引や、それに準じた高いセキュリティ水準を求める場合に確認する基準と捉えておくとよいでしょう。
ISMS・プライバシーマークの位置づけをより詳しく知りたい場合は、ISMS認証取得の開発会社に発注する5つのメリットやプライバシーマークとは？開発会社選定で過信せず正しく活用する方法もあわせてご覧ください。
「どれがあれば安全」ではない｜サービスの性質に応じて見る基準が変わる
比較表から分かるのは、4つの制度は「優劣」で並ぶものではなく、それぞれ守備範囲が異なるということです。SOC2はクラウドサービスの内部統制を細かく確認したいときに有効で、ISMSは組織全体の情報セキュリティ管理体制を、プライバシーマークは個人情報の取り扱いを、ISMAPは政府調達水準を確認したいときに見る基準です。
したがって、判断の出発点は「自社が利用するSaaSで、何を最も気にしているか」です。たとえば個人情報を大量に預けるサービスならプライバシー保護の観点（プライバシーマークやSOC2のプライバシー基準）を、止まると業務が回らない基幹に近いサービスなら可用性の観点を重視する、という具合です。
「SOC2があるから安全」「ISMSがないからダメ」と単一の基準で機械的に判断するのではなく、サービスの性質に応じて見るべき基準を選ぶ。これが、複数の認証が乱立する状況に振り回されないための判断軸です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
SOC2レポートの入手方法と読み方
SOC2が「中身を読むレポート」である以上、発注者にとっては「どうやって入手し、どこを見ればよいか」が実務上の関門になります。ここを押さえると、社内チェックでの説明にぐっと自信が持てるようになります。
入手方法｜NDA締結が前提になることが多い
SOC2レポートは、ベンダーの内部統制の詳細が記載された機密性の高い文書です。そのため、Webサイトで誰でもダウンロードできるように公開されているケースは多くありません。多くの場合、営業窓口や問い合わせフォームを通じて請求し、秘密保持契約（NDA）の締結を前提に開示される、という流れになります。
実務としては、導入検討の早い段階で「SOC2レポートを開示いただけますか。Type2はありますか」とベンダーに確認しておくとスムーズです。レポートの開示にNDAが必要なこと自体は一般的な対応であり、むしろ機密文書として適切に管理されている証ともいえます。
レポートの4パート構成と読みどころ
SOC2レポートは、おおむね次の4つのパートで構成されています（参考: SOC2レポート –レポートの構成–（令和監査法人））。発注者として特に注目したい読みどころとあわせて整理します。
- 受託会社監査人の意見: 監査人が、内部統制について総合的にどう評価したかを示すパートです。最初に確認すべき最重要箇所で、特に「意見の種類」に注目します。条件なしに適正と認められる意見（無限定の意見）なのか、一部に限定が付いた意見なのかで、信頼性の読み取り方が変わります。
- 受託会社の経営者の確認書: サービスを提供する事業者の経営者が、記述内容について責任を持つことを表明する文書です。
- システムの記述: 評価対象となったサービスの内容、約束しているサービス水準、そして設計・運用している内部統制の仕組みが詳細に記述されます。ここで「何が評価対象だったのか（評価範囲）」を確認できます。
- 監査人が実施した運用評価手続とその結果: 監査人がどの内部統制に対して、どのような手続でテストを行い、その結果どうだったかが記載されます。ここで注目すべきは「例外事項（逸脱）」です。テストの過程で不備が見つかった場合、その内容や件数が記載されるため、「監査を受けた＝完璧」ではなく、何が見つかっていたかまで確認できます。
読み方のコツは、「監査人の意見」で全体評価をつかみ、「システムの記述」で評価範囲を確認し、「運用評価手続とその結果」で例外事項をチェックする、という順番です。この3点を押さえれば、レポートを前にして「どこを見ればいいか分からない」という状態は脱せます。
SOC2があっても保証されないこと｜過信しないための限界
SOC2は強力な判断材料ですが、「取得しているから全部安心」と過信してしまうと、かえって重要な確認を見落とします。社内で「このSaaSはSOC2取得済みなので問題ありません」と説明する前に、次の限界を理解しておきましょう。
SOC2の5つの限界
- 認証ではなくレポートであり、合格証ではない: 前述のとおり、SOC2は「合格／不合格」を示すものではありません。中身（評価範囲・期間・所見）を読まなければ、確認したことにはなりません。
- 対象範囲はセキュリティ以外は任意: 必須はセキュリティのみで、可用性・機密保持・プライバシーなどが評価されているとは限りません。自社が気にする観点が評価対象に入っているかを必ず確認します。
- Type1は時点評価にすぎない: Type1は特定時点の整備状況を見たものであり、その後の継続的な運用までは保証していません。
- 例外事項（不備）が見つかっている場合がある: 監査の過程で逸脱・不備が記載されていることがあります。意見が適正であっても、運用評価手続の結果に注意すべき例外が残っていないかを確認しましょう。
- 評価対象期間が古い場合がある: レポートはある期間を対象に作成されるため、提示されたレポートが何年も前のものだと、現在の運用状況を反映していない可能性があります。最新版か、対象期間がいつまでかを確認します。
「ある／ない」の二択で判断しない｜中身と鮮度を見る
これらの限界を踏まえると、SOC2を「持っている／持っていない」という二択のチェックボックスとして扱うのは危険だと分かります。大切なのは、「SOC2を取得しているか」だけでなく、「どの基準まで・どの期間を・いつ評価したレポートで、例外事項はなかったか」という中身と鮮度まで踏み込んで見ることです。
逆に言えば、ここまで確認できていれば、社内のセキュリティチェックや稟議で「このSaaSは、SOC2 Type2でセキュリティと可用性が評価され、直近期間で重大な例外事項はありませんでした」と、根拠を持って説明できるようになります。これこそが、SOC2を判断材料として正しく使いこなしている状態です。
SaaS発注時のセキュリティ確認チェックリスト｜SOC2の先に見るべきこと
SOC2レポートを正しく読めるようになっても、それだけでSaaSの安全性をすべて確認できるわけではありません。SOC2でカバーされる範囲とされない範囲を切り分け、足りない部分は別の方法で確認することで、初めて発注者としての確認が一通り完了します。
SOC2レポートで確認できること／できないこと
確認したいこと | SOC2レポートで分かるか | 補足 |
|---|---|---|
内部統制の設計・運用状況 | 確認できる | 評価範囲・期間に応じて |
アクセス制御や情報管理の仕組み | 確認できる（セキュリティ基準） | 必須項目のため基本的に対象 |
データの保管場所（国内／海外） | レポートの記述次第 | 明記がなければ別途ベンダーに確認 |
インシデント発生時の通知フロー | レポートの記述次第 | 契約条件として別途確認が必要なことが多い |
契約上のセキュリティ条項 | 確認できない | 契約書・SLAで別途取り決める |
再委託先（サブプロセッサ）の管理 | 一部記述あり | 詳細は別途確認が望ましい |
このように、SOC2レポートはセキュリティ管理の「仕組み」を確認するには有効ですが、データの保管場所や契約上の取り決めといった、発注者が個別に詰めるべき条件まではカバーしきれません。
発注時セキュリティ確認チェックリスト
SOC2レポートの確認に加えて、SaaS発注時には次の項目を確認しておくと、抜け漏れのないチェックになります。
- データの保管場所: データが国内・海外のどこに保管されるか。海外保管の場合、準拠する法令やリスクを把握しているか。
- インシデント対応体制: 情報漏えいや障害が発生した際の対応体制と、利用企業への通知フロー・通知の時間目安が定められているか。
- 事業継続計画（BCP）: 災害や大規模障害時にサービスを継続・復旧する計画があるか。バックアップ体制はどうか。
- アクセス制御・権限管理の可視性: 自社側で利用者の権限を適切に管理できる機能があるか。操作ログを確認できるか。
- 再委託先（サブプロセッサ）の管理: ベンダーが利用する外部サービス（クラウド基盤など）が明示され、適切に管理されているか。
- 契約上のセキュリティ条項: セキュリティ要件・責任範囲・データの取り扱いが契約書やSLAに明記されているか。
これらは、SOC2レポートの「中身」と組み合わせることで効果を発揮します。たとえばインシデント対応や契約条項については、外注・委託の文脈で整理したシステム開発の外注契約で押さえる情報セキュリティ条項チェックリストも参考になります。SaaSを内製開発と比較して選ぶ段階の判断軸については業務効率化ツールの選び方｜SaaSと受託開発を業務独自性で判断が、発注先全般を評価する枠組みについてはシステム開発のベンダー選定基準6項目が役立ちます。情報セキュリティの基礎から押さえ直したい場合はITガバナンスとは？発注者が知るべき情報セキュリティ基礎もあわせてご覧ください。
よくある質問（FAQ）
SOC2は認証ですか？
いいえ、SOC2は認証ではなく監査報告書（レポート）です。「合格／不合格」を示す認証マークが付与されるものではなく、監査人が内部統制を評価した意見と発見事項が文書としてまとめられます。そのため、確認の際は「持っているかどうか」だけでなく、レポートの中身を読むことが前提になります。
Type1とType2はどちらを確認すべきですか？
継続的に安全な運用がされているかという裏付けを求めるなら、一定期間の運用状況まで評価したType2を確認するのが望ましいです。Type1はある特定時点の整備状況を見た評価であり、その後の運用までは保証していません。新しいサービスではType1から始めるのが一般的なため、Type1しかない場合は「現時点では時点評価にとどまる」という前提を理解した上で判断しましょう。
SOC2とISMS（ISO27001）の違いは何ですか？
最も大きな違いは「評価対象」と「形式」です。SOC2はクラウド・SaaS事業者の内部統制を対象とした監査報告書（レポート）であるのに対し、ISMSは組織全体の情報セキュリティ管理体制が規格に適合していることを示す第三者認証です。SOC2は中身を読んで評価範囲・所見を確認し、ISMSは認証の有無と適用範囲を確認する、という使い分けになります。
SOC2レポートはどうやって入手しますか？
多くの場合、ベンダーの営業窓口や問い合わせフォームを通じて請求します。レポートは機密性の高い文書のため、秘密保持契約（NDA）の締結を前提に開示されるケースが一般的です。導入検討の早い段階で「SOC2レポートを開示いただけますか。Type2はありますか」と確認しておくとスムーズです。
SOC2を持っていないSaaSは使わない方がよいですか？
一律でNGとは限りません。SOC2は有力な判断材料の一つですが、ISMSやプライバシーマークなど他の認証、あるいはデータ保管場所・インシデント対応・契約条項といったチェックリストの観点を組み合わせて総合的に判断するのが現実的です。サービスの性質と、自社が最も気にする観点に照らして、必要な確認手段を選びましょう。
まとめ｜SaaS発注者がSOC2をどう使うか
SOC2は、SaaSの信頼性を見極める発注者にとって、非常に有力な判断材料です。ただし、認証ではなく「報告書」であるため、その価値は中身を読むことで初めて引き出せます。本記事の要点を、持ち帰れる判断軸として整理します。
- SOC2は認証ではなく監査報告書。「持っている／いない」ではなく、評価範囲・期間・所見という中身を読む
- 評価対象の5基準のうち必須はセキュリティのみ。自社が気にする観点が対象に入っているか確認する
- Type2は運用実績まで評価したもの。継続的な運用の裏付けを求めるならType2を優先する
- ISMS・プライバシーマーク・ISMAPとは目的と形式が異なる。サービスの性質に応じて見る基準を選ぶ
- SOC2でカバーされない、データ保管場所・インシデント対応・BCP・契約条項などはチェックリストで補完する
次のアクションとしては、まず自社のセキュリティチェックシートに「SOC2のType・評価範囲・例外事項・対象期間を確認する」という観点を反映してみてください。そして、検討中のSaaSベンダーにはレポートの開示を請求し、本記事で紹介した読みどころに沿って中身を確認すれば、社内の稟議やチェックで自信を持って説明できるはずです。複数の認証が乱立する状況に振り回されず、自社なりの判断軸を持つことが、安全なSaaS選定の出発点になります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
