詳しい内容は、SOC2総合サイトをご覧ください。

SOC2総合サイトはこちら

SOC1やSOC3との違い

Type1とType2の違い

SOC2の取得目的

独立した第三者（監査法人や監査事務所）が評価したレポートであり、国際的に効力のあるレポートであるため、ユーザーに信頼感を与えることができ、営業のためのツールとして取得されるケースが多いです。

• 顧客や取引先に対し、提供サービスの信頼性を客観的に証明したい
• ISMSやPマークよりも一歩進んだ客観的評価を取得したい
• 提供サービスのグローバル展開や外資系企業への営業を考えている
• 公共性の高いサービスや顧客情報を大量に取り扱う企業向けに信頼性を証明したい
• 費用対効果の高い営業ツールがほしい

SOC2レポートの記載内容について

記述書には以下の情報が含まれます。

• 提供される業務の種類
  受託会社によって提供される業務の内容が記載されます。
• 主要なサービスコミットメント及びシステム要求事項
  委託会社の顧客等に対して約束されたコミットメントと、それを達成するために必要なシステムの要求事項が記載されます。
• 業務提供に利用されるシステムの構成要素
  受託会社が業務を遂行するために必要なインフラストラクチャー、ソフトウェア、人員、手続き、データについて記載されます。
• 識別されたインシデントの内容
  関連するインシデントについて記載されます。
• 統制環境、リスク評価、情報と伝達、監視活動及びITへの対応
  これらの項目に関する内容が記載されます。
• システムに関する内部統制
  受託会社のサービスコミットメント及びシステム要求事項が満たされることについて、合理的な保証を提供するためにデザインされた関連する内部統制が記載されます。
• 相補的な委託者の内部統制
  詳細は後述します。
• 相補的な再受託会社の内部統制
  詳細は後述します。

SOC2に係る基準等

取得までの期間

①SOC2準備期間 → ②Type1 → ③Type2という流れで進行するのが一般的です。
SOC2準備期間は、システム統制の構築を一定の水準にまで持っていくフェーズであり、個社のシステム統制の構築状況や、システム統制の改善にかかるコストとリソースの多寡によって、この期間は異なりますが、少なくとも2～3カ月は見込む必要があります。
Type1の段階では、①のSOC2準備が完了していることが前提ですが、少なくとも1カ月程度の期間が必要です。
Type2の期間は、短くても半年かかり、その後、監査事務所による検証期間としてさらに3カ月を要すると考えると、Type2の期初からSOC2保証報告書の発行までには、最低でも9カ月を要します。（対象期間が1年の場合は、最低でも1年3カ月かかります）
例として、SOC2準備を2024年8月にスタートし、Type2の保証期間を1期目は半年とした場合、SOC2の報告書受領日は最短でも2025年8月となります。

1. ①SOC2準備期間: 2024年8月～2024年10月
2. ②Type1の報告書受領: 2024年11月（基準日: 2024年10月末）
3. ③Type2の報告書受領: 2025年8月（検証期間: 2024年11月～2025年4月）

取得までにかかる費用（コスト）については、下記参照。

Type2のレポートの対象期間は？

評価期間は少なくとも半年で、通常は1年間を対象にして内部統制の検証が実施されるケースが多いです。

SOC2取得までのコスト

以下はSOC2取得における平均的な費用です。個社のシステム統制の強度や、SOC2の対象範囲、対象とするサービスの規模、システムの複雑性、関連資料の整備状況により、費用は変動します。お見積りについては、下記のお問い合わせフォームまでご連絡ください。

• 準備コンサルティング: 約300万
• Type1: 約200万
• Type2: 約500万

なお、ISMSなどの取得状況やセキュリティレベル、Vanta等のリスクコンプライアンスツールの導入状況によって、報酬は前後することがあります。

いきなりTYPE2から入るのは危険？

SOC2準備コンサルティングやType1から始めることを強くお勧めします。
SOC2レポートでは、対象期間内におけるシステム統制についての検証結果が詳しく開示されます。システム統制が十分に整備されていない状態でいきなりType2に突入すると、期中に予期せぬエラーが発生し、「システムが適切に整備されていなかった」という内容の報告書となってしまう可能性が高くなります。これでは、SOC2の取得目的に反し、本末転倒な結果となることが想定されます。
また、SOC2レポートの結果として、上記のように「システムが適切に整備されていなかった」旨の意見が表明される可能性が高くなったからといって、「問題ない」旨の意見を監査事務所からもらうために、途中で都合よく検証対象期間を変更したり、エラーが生じた範囲を検証範囲からはずしたりできない点については留意が必要です（保証業務実務指針 3702）。
したがって、SOC2レポートが本末転倒な結果にならないよう、事前にSOC2支援コンサルティングを受け、システムに係る内部統制が適切に整備された状態になってからType2に入ることを強くお勧めします。

日本でもSOC2の普及率は拡大する？

国内のクラウドサービス事業者は、ISMSやPマークなどの「認証系」資格の取得率が高い一方で、欧米系のクラウド事業者はほとんどの事業者がSOC2レポートを取得しています。（出所：PwCあらた有限責任監査法人、クラウド・リスク・マネジメント、P129）
外資系企業がユーザーとなる場合、本国ではSOC2の取得がスタンダードとなっているため、日系企業にもSOC2の取得を求められることがよくあります。ユーザーからの継続評価（セキュリティチェックシート等）の際に、SOC2の取得可否が問われることがあります。ISMS等の認証系資格については、近年その信頼性に対する見方が変わりつつあり、SOC2の取得がなされていないと契約の継続が難しくなるケースも増えてきています。昨今、SOC2は費用対効果の高いツールとして認識されつつあります。

SOC２取得コンサル事業者の選定のポイント

最終的にSOC2レポートの内容を検証し、SOC2報告書にサインするのは監査法人（監査事務所）です。つまり、初めにSOC2支援コンサルティングによって事前準備が行われ、システムに関する内部統制の構築が完了しても、監査事務所によるSOC2の検証業務が始まってから初めて、問題ない旨のレポートを得るためには、内部統制が十分でないとの指摘を受けることがあります。これは、SOC2支援コンサル業者と監査事務所との間での温度感の違いが原因です。この問題を解決するためには、監査事務所との密なコミュニケーションを取りながら進められる、あるいは、監査事務所におけるSOC業務に対する考え方や方針について深く理解しているコンサル業者を選定することが必要です。

５カテゴリーについて

• セキュリティ（Security）
  組織は、情報やそれを格納するシステムを保護するために、不正アクセスや情報漏洩を防ぐ適切なセキュリティ対策を実施する必要があります。具体的には、認証・認可によるアクセス制御の実装、保存・転送するデータの暗号化、物理アクセスの制御、ネットワークセキュリティの実装などが求められます。
• 可用性（Availability）
  組織は、顧客に提供する製品・サービスが合意した通りに操作・使用できるよう、運用・モニタリングのための対策を実施する必要があります。具体的には、システムの冗長性の確保、システムの監視とアラート、データバックアップの実施、災害復旧プランの策定・実施、サービスレベルアグリーメント（SLA）の設定などが求められます。
• 処理のインテグリティ（Processing Integrity）
  組織が行うシステム処理は、完全で正当、正確かつ適時に実施され、かつ承認されている必要があります。そのために、データの検証や整合性チェック、データの改ざん防止対策、データの履歴とトレーサビリティの確保、データ処理の監視とエラーハンドリングなどを実装する必要があります。
• 機密保持（Confidentiality）
  組織は、営業秘密や知的財産などの情報を収集・生成から廃棄まで保護する必要があります。そのために、適切なアクセス制御の実装、データの分類とラベリング、データ転送時の保護、安全なデータの破棄、データアクセスのモニタリングなどの対策を実施する必要があります。
• プライバシー（Privacy）
  組織が扱う個人情報が、適切に収集、利用、保持、開示および廃棄される必要があります。そのために、プライバシーポリシーの策定と公開、個人情報を収集する際の同意の取得、適切な範囲での情報の共有と第三者提供、権利に基づく削除要求への対応などの対策を実施し、個人情報の保護に努める必要があります。

5カテゴリーのうち、選択するカテゴリーは会社が自由に選択できるのか？

セキュリティについては必須記載項目ですが、可用性、処理のインテグリティ、機密保持、およびプライバシーは任意記載項目です。これらの任意項目については、会社の都合で選択することはできず、あくまでもユーザー視点で選択する必要があります。つまり、ユーザーにとって重要と考えられる項目を選択しなければなりません。
また、受託会社が選択したカテゴリーに関する規準は、SOC2レポート上にすべて含まれる必要があります。（出所：保証業務実務指針 3702）
これは、TSPセクション100「2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy」（AICPA「Trustサービス規準」）において、各Trustサービスカテゴリーにおける規準が提示されているのだが、そこに記載の基準については全てSOC2レポートに記載する必要があり、勝手に除くことはできないということを意味しております。

相補的な内部統制

SOC2報告書を利用する際には、留意すべき事項の一つとして「相補的な内部統制」があります。相補的な内部統制とは、日本公認会計士協会の実務指針において「受託業務をデザインする段階で、委託会社において整備されることを受託会社が想定する内部統制であり、受託会社のシステムに関する記述書において、統制目的の達成に必要な内部統制として識別され、記載されるもの」と定義されています。
つまり、受託会社（ベンダー）は、委託会社（ユーザー）側が適切なアクションを取ることを前提に業務を行います。例えば、クラウドサービスにアクセスする人が、ユーザー側で適切に承認された人に限定されている必要があります。このアクセス権の管理はユーザー側で行う内部統制であり、そのような統制は「相補的な内部統制」としてSOCレポート上で示され、ユーザーの責任として注意喚起がなされます。
同様に、「再受託会社の相補的な内部統制」も存在します。再受託会社とは、SOC報告書を提供するサービス事業者（受託会社）が、一部のシステムについて外部のサービスを利用している場合、その外部サービスを提供する事業者です。再受託会社の内部統制は、サービス事業者（受託会社）の管理下にないことがあるため、統制目的の達成に必要な内部統制については、注意喚起のためSOC2報告書上に記載されます。実務上は、AWSが再受託会社として取り扱われることが多く、AWSにおける内部統制が再受託会社の相補的な内部統制として記載されているケースが多く見受けられます。

再受託会社の扱い_除外方式とは？

受託会社が受託業務の一部を再委託する場合における、受託会社の内部統制の保証報告書上での再受託会社の提供する業務の取扱いについて除外方式と一体方式という２種類の方法があります。除外方式が採用されているケースが多く見受けられますので、ここでは除外方式についてご説明します。
除外方式では、SOC2報告書に再受託会社に再委託している業務の内容が記載されますが、再受託会社の内部統制は、SOC2報告書及び監査法人（監査事務所)の検証の範囲から除かれます。ただし、SOC2報告書及び監査法人（監査事務所)の検証の範囲には、再受託会社の内部統制の有効性をモニタリングする受託会社の内部統制が含まれることには留意が必要です。（保証業務実務指針 3702）